So I'm going to bite the bullet and learn about version control, something I should have done a while back...
But I have a situation I'm not sure how to resolve.
I have a somewhat large game engine, which much like Irrlicht and its Tutorials, has projects using the engine in subdirectories. This is nice as the entire engine and projects using it can be built at the same time with CMake.
But one reason I am moving to version control is that sometime I may want to make my engine open source. But I won't want to open source the individual projects (games) of mine which use the engine.
So now I have the dilemma of how to organise all this stuff. I see two options:
1) seperate each individual game project to a separate repository, with its own structure not related to the engine. Keep the engine separate and compile and copy + paste across latest binary releases of the engine to the individual projects.
I don't like this approach since it means making new cmake scripts and such for each project. It is however very simple to understand.
2) Keep the project subdirectories as they are. Some projects I open source can remain there, such as engine tests and examples. Then, for my closed source projects I create a clone of the main engine source and develop them separately.
With this option, I have to make any changes to the engine in the main engine repository and then the clones must have these changes propagated to them somehow when I want to update to the latest version of my engine. I'm assuming version control supports things like that.
I'm guessing (2) is the route to go, but it seems a lot of hassle to have to develop my engine and games in two separate places and having to propagate engine changes across.
Opinions? What other options are there?
version control
Why do you need to copy your game engine? I have everything in seperate folders (although it's all open source), and when I compile it I just link to my .a files generated in some other folder. Or maybe do it like this:
With the makefile in the main folder you trigger the makefiles in the subfolders, and depending on what you want to share you add the subfolders to SVN (only the engine in this case ).
Code: Select all
+ main folder
|
| (makefile)
|
+--+ engine
| |
| | (makefile)
|
+--+ game1
| |
| | (makefile)
|
...
Dustbin::Games on the web: https://www.dustbin-online.de/
Dustbin::Games on facebook: https://www.facebook.com/dustbingames/
Dustbin::Games on twitter: https://twitter.com/dustbingames
Dustbin::Games on facebook: https://www.facebook.com/dustbingames/
Dustbin::Games on twitter: https://twitter.com/dustbingames
-
- Posts: 288
- Joined: Wed Apr 16, 2008 1:45 am
- Contact:
-
- Posts: 288
- Joined: Wed Apr 16, 2008 1:45 am
- Contact:
yeah, if you use subversion there is a config file (in each repository) which contains the ability to make certain folders public or private. I haven't had the need to distinguish between them so I don't have any more specifics. Google will help though/ you can then use a back up program to back up the repository folder and all info is retained.
We use Mercurial here and love it. We have the engine and all games using the engine, as well as libraries they rely on in seperate repos. (Smaller libraries are grouped into one larger libs repo.)
The main pitfall of this is that you have to separately commit/push repos, and you have to make sure you document which engine revision the game revisions match up with. However it has worked great for us!
~David
The main pitfall of this is that you have to separately commit/push repos, and you have to make sure you document which engine revision the game revisions match up with. However it has worked great for us!
~David