Which version control supports merging in multiple releases?

Imagine you have a large software project where you have to support several branches (releases) at the same time. For instance you have a production release on the website, a integration test release that is currently tested by the customer, a testing release that for your local systems test and a development release where your developers are hacking away new features.

What version control system supports this setup well? My main concern is that it should support merging between the different releases - if you fix an urgent bug in your production release you do not want to check out all other releases as well and fix the bug by hand 5 times.

If you have an answer I would like to hear how big the project you applied it in was and what experiences you had. I am looking for a system that explicitly supports merging by the developer - solutions with scripts applied by build managers etc. won't help us. (Too dangerous; the merge should be done by the developer immediately since he/she knows best what to do.) Thanks so much!

From stackoverflow

• It is possible to configure Telelogic CM Synergy/CM to support such a setup.

  The good point is that all "higher" releases are updated automatically without developer or build manager actions if the file is unchanged in those releases. If the modified file is changed, the developer is notified immediately on checkin and has to merge the stuff. It supports grouping of related changes into tasks and change requests and has an associated tracking system for those.

  The bad points are that it is really big and slow, needs a lot of buildmanager time and the eclipse integration is almost unusable. You'll probably need a fulltime buildmanager each 5 or 10 developers.

• Clearcase will handle multiple branches and revisions, and merging between any/all of these. You can define branches at will, labelled as you desire, and merge to/from these. Needless to say, this can get extraordinarily complicated and IBM provides a merge manager to help you. You can display the branches graphically (if that helps).

  Clearcase is amazingly powerful, but correspondingly complex and time-consuming to manage.

  hstoerr : Does the developer merge at checkin time or later a buildmanager? (The latter probably does not understand the changes, so I think it should be the developer.)

  Brian Agnew : You can check into a branch, then merge back/forth completely independently of the checkins. You should (of course) understand what the results of your merge will be :-)

  Brian Agnew : (to clarify the above, I don't think you necessarily have assigned roles - developer vs build manager etc.)

• Team Foundation Server supports any number of branches, with merging. It's pretty good as it is, but the features of the 2010 release make branching even more compelling. See 10-4 Episode 4: No More Parallel Development Pain.

  ck : Branching is working great for me in TFS 2005 (most of the time...)

  John Saunders : I used TFS 2008, though I don't know if that's something that changed between the releases.

• In my experience merging with subversion works, but is quite painful (though I've heard newer versions are better in this respect). Git and Mercurial do merges properly with no problems.

• I think most, if not all, modern SCMs can do that. Not necessarily automatically, although some scripts can handle that in a quite painless way.

  At work, we use Perforce, and we do the integrations by hand (helped by a Perl script to copy changelist information). We carefully choose which changelists go to release (we can discard risky ones, for example).
  For most distributed VCS (Mercurial, Bazaar, probably Git, etc.), working with several branches (or clones) is the natural workflow.

  hstoerr : Such scripted solutions are probably executed by build managers, aren't they? My problem here is: the build manager has no knowledge about the merged code and thus is not able to resolve conflicts. Ideally the developer should resolve conflicts in different versionds on checkin or immediately after the checkin.

  PhiLho : Indeed the build manager do the integrations, in most cases the merge utility is smart enough to solve most problems, and some conflicts are trivial enough to be solved by him (eg. in comments, or empty line vs. line with space...). At worst, he asks for help to the related developer (we are a small team...). Or in some cases just delegates the integration.

• If you really want to handle multiple releases but not suffering the pain of Clearcase you should try something like Accurev or PlasticSCM.

  Accurev is very powerful dealing with its streams, you've to get used to them but once you do it's very, very powerful.

  Plastic is more powerful in terms of handling unlimited number of branches (and their corresponding merges) something easier said than done. You've all the flexibility mentioned for good-ol CC but without the arcane commands or weird configurations.

  Here you've the branch explorer tracking multiple branches

  

• The answer to this question is one of process first, and toolchain second.

  You need to decide how you wish to access known versions (e.g. "what's on production?"), how you want to make changes to those and how you want to disseminate changes to other versions.

  Most VCS systems that are Subversion-Or-Better will support common workflows. Here is one that is common:

  1. Development is on the trunk
  2. When it's time for a release, tag the trunk, e.g. 1.3.0
  3. Create a branch off of the trunk at the tag you made, e.g. 1.3.x
  4. Release the code based on the ''tag'' (e.g. 1.3.0)
  5. Resume development of new features on the trunk
  6. If you need to fix a bug in production, check out the branch and fix it. Release that as normal, creating a new tag (e.g. 1.3.1).
  7. Merge changes from your branch back to the trunk as needed
  8. Repeat steps 6 & 7 as needed until your next release.

  Here is another common practice:

  1. Development is on the trunk
  2. When it's time for a release, tag the trunk
  3. Release to production based on the ''tag' (e.g. 1.3.0)
  4. If a bug is found, create a branch to fix that bug against the tag
  5. Commit on the new branch, and re-tag (e.g. 1.3.1)
  6. Merge that branch back to trunk
  7. Repeat steps 4, 5, & 6 whenever you find a bug

  These are very common and simple to implement/understand; they are easily supported by most version control systems. If you get more complex processes, you will reduce the toolset available, but possibly have more power.

  hstoerr : The problem with this traditional approach is that the merging must be done by a buildmanager who does the tagging etc, and the build manager usually has no knowledge about the merged code. Or am I missing something? Can the developer do it without executing a manual change 4 times in all branches?

  davetron5000 : Someone has to merge, so why would you have someone unfamiliar with the code to do it? If your version control system and policy requires a full-time employee, you should consider refactoring that policy and getting a better system. Note that you could add on a more rigorous/bureaucratic config. mgmt. scheme on top of these steps, which are focussed on keeping track of the code in a structured way.