Which version control supports merging in multiple releases?

Question

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!

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.