🔒 Locked

Version control and modules

Started by Numsgil Oct 5, 2008 at 6:00 PM 2 replies 1.6k views

Original Post

Numsgil

110

Numsgil

Oct 5, 2008 at 6:00 PM

My C# project is highly modular. The idea being that I can swap out the AI module for a different one at run time, for instance. Likewise physics, etc. My thinking is that the different modules are going to have different development paces, so the AI module might not change for months, while the physics module undergoes rapid development. When it comes time to create a periodic release for the whole program, I may not want to use the latest physics, since it might be buggy, and instead I'd use the last stable physics release from a few weeks ago. But maybe I've fixed an AI bug in the mean time, and I want to include that bug fix. This lead me to the idea of handling versioning for the sub modules independently from each other. I could include version 1.2 of physics and 0.9 of AI, or whatever. I bundle the modules I want for a master release, and call the master release by its own version number (maybe 1.56 in this example). I can do experimental work on physics without branching the entire project, which will hopefully make merging easier. And if need necessary I can hotswap different versions of modules in to isolate bugs. There are probably some other advantages to this method as well. The hard part is managing version control (I'm using SVN). Suppose I have maybe a dozen modules, and they each have trunk, tags, and branches folders. There are several problems I can think of with this method. For instance, how would I manage tagging master releases? Maybe master release tags are just scripts that sync the different modules to the right versions? And if someone else makes changes to several modules and I want to sync to trunk on all of them, same issue. Maybe I just create some scripts to handle syncing on all the modules? It feels like this could spiral out of hand really quickly, but there are enough advantages for me not to dismiss it out of hand. Is this a good idea, or not?

OrangyTang

335

OrangyTang

Oct 5, 2008 at 7:30 PM

Do you actually need separate trunk/tag/branch dirs for every module? Which you may need to branch off one module it's likely that'll be the exception rather than the rule, so you could have a single branches dir with them all in appropriate sub dirs. Similarly you're only going to have one "cutting edge" version of everything, so that'd go in your trunk. Tags could be per-module or more likly they'll be a particular combination of all your modules so again you can just use a single top-level tags dir. Eg. something like:

\trunk  ..cutting edge code..\branches  \ExperimentalPhysics1  \ExperimentalPhysics2  \OldRenderer\tags  \version1_0    \Physics    \Renderer    \AI  \version1_1    \Physics    \Renderer    \AI

sphen_lee

Oct 5, 2008 at 7:42 PM

If you are concerned about the ease of merging, perhaps you should try a version control system like Mercurial, Bazzar or Monotone that can automatically keep track of merges. This way you don't need to worry about branching the entire project.
Personally I use Mercurial and find it very powerful.

Numsgil

Author

110

Numsgil

Oct 5, 2008 at 9:12 PM

Quote:
Original post by OrangyTang
Do you actually need separate trunk/tag/branch dirs for every module? Which you may need to branch off one module it's likely that'll be the exception rather than the rule, so you could have a single branches dir with them all in appropriate sub dirs. Similarly you're only going to have one "cutting edge" version of everything, so that'd go in your trunk. Tags could be per-module or more likly they'll be a particular combination of all your modules so again you can just use a single top-level tags dir. Eg. something like:

*** Source Snippet Removed ***

I'm not sure if I need separate dirs or not. I don't want to be in the position of releasing bug fixes for AI and introducing bugs in physics, which I'm apt to do. Another alternative is to branch a tag, apply the bug fix to both that new branch and the trunk, and then tag that new branch with a new minor version number when enough patches have accumulated. My experience with branching and merging is strictly book learning, but it seems that trying to do something like that is going to be a huge pain.

Quote:
Original post by sphen_lee
If you are concerned about the ease of merging, perhaps you should try a version control system like Mercurial, Bazzar or Monotone that can automatically keep track of merges. This way you don't need to worry about branching the entire project.
Personally I use Mercurial and find it very powerful.

I barely understand SVN :) I just don't have the mental effort to learn another version control system. Plus I have some sunk costs in SVN (SVN hosting and the like).

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.