What's the best way to handle multiple simultaneous "streams" of development in version control?

Question

My department is planning on working on our next several releases (spanning a year) simultaneously. The powers that be are advocating we support this by refactoring all affected code into classes like AbstractGizmo, R1Gizmo, R2Gizmo, etc and use configuration (via Spring and/or ANT) to control which classes are used in a particular release. Ostensibly this is to save us the work of merging changes into multiple branches, especially when the changes are in the common code. However, I see this as a clear cases for branching and merging in version control (TFS, in our case).

However, I have very little experience on projects that have active streams of development like this. I'm sure others have (like Microsoft, with Windows XP, Vista, and 7). What's the best way to handle multiple simultaneous "streams" of development in version control? Do you branch and merge changes in version control, try to develop everything in one branch and use configuration or build scripts to assemble the different version, or something else?

P.S. We use TFS right now, but our version control strategy may not be constrained by it. A coworker of mine is pushing to switch to Git or Mercurial, and it seems like he's getting a bit of traction.

Answer 1

As you suspect, this is a clear use-case for a VCS. But... not all VCSs handle merging very well. I can't speak to TFS, but Subversion's merge tracking leaves a lot to be desired. The DVCSs such as Hg and Git handle merging much better. Merges aren't always simple, and I've found that a lot of developers have trouble with even relatively simple merges. If you have one or two people who are willing to get good at dealing with merges, that will help.

I would recommend that you test the merging of TFS with some trivial little example app, where you rename files and modify the same file in a different branch, merge multiple times from one branch to another, etc.

The multiple-versions-in-one-tree approach you describe seems like it would yield a real nightmare when you get close to your first release and realize that you're going to have to do some refactoring or significant interface change for your second release. You're not going to want to make such drastic changes to the codebase close to a release, but you're not going to want to delay the change for the work you need for the second release. If you aren't branching, it's going to be hard to make that live in the same tree of files.

Answer 2

I agree with retracle, and to add some TFS experience. Merging can be painful so you need to do it as often as possible to reduce the number of simultanious conflicts. Don't save it up till one of your streams is nearly complete or you'll have a nightmare on your hands.

Read the ALM rangers guidance and you should be set. Hopefully you're using TFS 2010 as the merging is significantly better than earlier versions.

You might also find this blog interesting. Brian Harry compares the merging experience between git, TFS 2010 and TFS 11

Answer 3

As pointed out in the other answers, this is the classical use case for branching & merging, so I'd also recommend to try this.

However, this is not the only solution. An alternative might be to use "feature flags":

Basically, any changes that are not supposed to be active (yet) are wrapped into an if block, so they can be switched on/off by configuration. Something like:if

($cfg.enable_unicorn_polo) {
    // do something new and amazing here.
}
else {
    // do the current boring stuff.
}

This has advantages and disadvantages compared to the branching&mergin solution, but it's good to know about it.

This is apparently how Flickr does their development. Source:

http://code.flickr.com/blog/2009/12/02/flipping-out/

Answer 4

If Branching does not work, Consider Continous Integration on build-server like Cruise Control. Each build on the build server should run all unit and integration tests (and possibly other checks like database consistency, code coverage etc.). If a build is unsuccessful, the person/persons that checked in should immediately fix this -- no other tasks should outrank build fixing besides death or childbirht (consider delaying both, if a build is broken). Check-ins by others should not be allowed before the fix is checked in and verified.

Note: Branching AND continous integration could work side by side.

Answer 5

Despite all the answers that tell you to go with merging instead, it is impossible to know whether this is a good idea or not without knowing a lot about the current state of the code and the intend behind the effort.

This may very well be a good and even conservative approach compared to merging. Real improvements and structural changes can be frustrated by a merging system that is basically designed and suitable for small, incremental changes.

It sounds like some thought went into this decision and likely some bad experiences with merging. I suggest you figure out what those were first and include that information in your question.