Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
2  
Definitely use separate branches, or at the very least, separate repositories. –  Bernard Dec 8 '11 at 17:30
2  
That "plan" (refactoring) is about the scariest thing I have ever seen someone seriously propose. If they actually implement that, it's definitely fodder for TheDailyWTF. –  ebneter Dec 8 '11 at 20:49
    
ditto to @ebneter most frustrating and counterproductive amount of duplicate code I ever seen was in project that has been "refactored" in a similar way. It took a little more than a year to bring a reasonably designed codebase into a complete mess and more than 1.5 years to get it back to manageable state after fiasco became evident –  gnat Dec 9 '11 at 12:46

4 Answers 4

up vote 5 down vote accepted

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.

share|improve this answer

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.

share|improve this answer

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/

share|improve this answer
    
Absent decent version control, build/release tools & languages supporting dynamic deployment, all this sounds entirely reasonable. ... But given that we actually DO have these (git+CI(jenkins)+IoC/DI+modules(OSGi)+et-al.+ your fav' JVM-langue-du-jour) makes this sound just plain nuts. Spaghetti Factories are to be studied as an anti-pattern, not as an option. Proclaiming "if(feature)...elseif(feature2)..." as an intentional design/development/deployment model with redeeming value might give these poor php proj's/dev's a bad rep... –  michael_n Jun 28 '12 at 2:43
    
@michael_n: Actually, there are advantages to using feature flags. It reduces the risks of problems at integration/merge time, and most importantly, allows to toggle individual features separately, even at deployment/runtime. If this is desired, feature flags are superior to branching. Of course, there are downsides, that's why I said so in my answer. –  sleske Jun 28 '12 at 7:16

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

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.