I’ll preface this by saying article is about subversion and not git. Since release 1.5, subversion now includes a property, svn:mergeinfo, that is auto-applied when preforming merges. Before this, a merge was pretty much an ad-hoc diff between two files or lines of code. The best practice was to include the merge command used in the SVN comment, which was extremely unreliable. For clients and projects not yet on the git-train, svn:mergeinfo is a welcome and painfully overlooked feature.

We, like many other teams, typically follow the TRUNK = “bleeding edge”, branch-releases pattern to SCM. So at the end of each iteration, we cut a release branch from TRUNK. This release is deployed and we turn our efforts toward the next sprint. However, is is atypical to not have to patch the release. This is usually done in the release branch, tested on a staging environment, the ultimately deployed to production. Afterward, the patch is merged back to the mainline development trunk. This pattern works nice, but sometimes we do a series of patches in the release and there is definitely the opportunity to miss a commit when merging. Since subversion previously didn’t have a way to see merges (merges were not directly tracked), the process involved a session of reviewing commit logs and manual comparison. Enter git, which is built to merge, and the mass movement to git is inevitable.

However, with subversion 1.5, a new property is introduced svn:merginfo. This feature add merge tracking to svn. So when committing the results of a merge, this piece of metadata is recorded. This opens up many new features, like looking at the svn:merginfo property (you shouldn’t edit this property, only get it).
And one of my favorite features is the --reintegrate option. So we can now tell, with a single command, what merges in the release haven’t made their way back to trunk — no more missing merges!

There are a few points, echoed here (parting thoughts section at bottom), worth mentioning:

  1. The subversion server and all developer clients ought to be at least running svn 1.5+
  2. Do all the merges from a standard location, like the project root (RAILS_ROOT for RoR)
  3. Inform developers of this property. After doing a merge, the svn:mergeinfo is put on the place the merge was preformed (preferably project root). So developers should know this and make sure to commit this property change.