Which version control tool is best suited to handle reflective or cyclic merging? SVN, Git?

Question

Reflective/Cyclic Merging

This is easiest to explain with an example. Suppose you are working on a feature branch copied from your trunk. During the development process you regularly merge ''all'' new changes from trunk to your branch so that the branch stays in "synch" with the work occurring on trunk. When you eventually merge your branch back to trunk, that is called a reflective (or cyclic) merge.

Refer to Subversion merge reintegrate article on http://blogs.open.collab.net/svn/2008/07/subversion-merg.html for more details. You can also refer to http://jugalps.wordpress.com/2009/07/31/svn-branching-and-merging-in-scrum/ to get an overview of a typical reflective merge process. My personal experience with SVN is not good enough when dealing with such kind of scenarios.

Does any one have experience working with any other version control tool apart from SVN for reflective merging?

Answer 1

Hello,

As you said reflective merging with SVN used to be a nightmare, but with latest version of svn 1.6.x series, there is much support for it (now merges save meta-data related to the merge in the history, that helps when merging back changes).

I currently use Bazaar as VC system (it is a distributed VCS, like Git), and i can say it has more support for branching and re-parenting/merging-back branches into main-line. Also Git has support for that (rebase), both are designed with branching/merging-back in mind.

Answer 2

IBM Rational's ClearCase product has major support for exactly this mode of operation - it is a standard way of working on development branches, and the merging is pretty much automatic in both directions (unless there are conflicting changes, of course). However, the rest of the infrastructure needed for ClearCase probably means you will only use it if your company makes a major investment decision.

Answer 3

Subversion, being more or less a huge bugfix for CVS, has similar problems with merging as CVS. Both were designed for really simple merge cases, not what we use today (hundreds of people working on the same code base with each one having a slightly different version).

Git and other modern DVCS were designed to solve this (plus the distributed VCS part). Git comes with a lot of different merging algorithms and it's easy to create a new one. But my guess is that it would be hard to come up with a scenario that the Linux kernel developers haven't seen so far ;)

From my personal experience, Git is a nice tool if you forget most that you know about SVN. Otherwise, you'll try to apply your SVN/CVS knowledge and that just won't quite work. Sit down, work through the tutorials and really start working as if you have never seen a VCS before. For example, I tried to put several projects into a single repository.

Answer 4

Git has always been designed with this ability in mind. It was my first VCS, and to me, this type of workflow is totally routine. In general, the merge (a push or requested pull) back to origin ("trunk") is trivial, since by regularly merging from origin, you have ensured that your HEAD (branch tip) has origin's HEAD in its past, so when origin merges your work, it merely has to move forward through the history, rather than actually perform a merge (git calls this a "fast forward").

Git's rebase capability can also be used to make the history even prettier. If you adopt this workflow, you can always rebase your work on top of whatever you pull from origin, rather than merging them. (This is rewriting history so you have to be sure not to do it with anything already published) That way, all of your merges from origin are fast forwards, and your work is just a single sequence of commits on top of origin's HEAD. This makes the history more direct - hopefully a straight line, instead of a series of lots of merges.

Answer 5

I recently switched all my new projects from SVN to git. All I can say is Branching and Merging is MUCH easier.

Branches are so easy to create and manage that practically every day's development gets a new branch, where I commit to my local branch, then merge back when I'm done. I'm working with a small group, and we've had no trouble working like this.