Subversion 1.5 Merge Tracking

Friday, October 3, 2008

This week, I made it my personal mission to learn as much as I could about branching and merging in subversion. This was prompted by a general need in my department to get a better handle on our large, multi-client, shared codebases. Up until last year, we used VSS. If you've ever tried using it for branching, it's not pretty. Doable, yes, but not ideal. I'd go so far as to say that for where I work, it simply wasn't robust enough to be an option. Over a year ago, I was given the go-ahead to do some new projects in subversion. This created some short-term and ongoing pain, what with some stuff in VSS And some in SVN. Still, it had to be done. Unfortunately, change is slow in large organizations, rightfully so sometimes. So we still haven't ported everything over to SVN yet, in part because there hasn't been a "killer feature" driving us to do so. I believe with Subversion 1.5, that killer feature is here: merge tracking. If you've ever tried merging with Subversion prior to 1.5, you know that you need to do it with revision numbers. This isn't too tough in easy cases, but consider: You create a branch. It's a long-running feature branch, maybe taking 2 weeks to complete. Ideally, you'd keep that branch up to date with the latest and greatest from trunk frequently, meaning you'd be merging from trunk to branch a lot. This becomes problematic because you have to keep track of your merge revision numbers; otherwise, you can get "double merges". If you don't keep a log, and you/others don't use good commit comments, it doesn't take long before you find yourself in this position. Personally... it's just tough to maintain. Subversion 1.5 merge tracking aims to eliminate that problem. Essentially, it keeps track of your merges so you don't have to. This way, you simply say "svn merge [TrunkURL]" and it does the deed. It remembers your previous merges. No more double merges. I've been working with it on the command line for a bit, and so far, it's great. But ideally, this functionality would be built into the GUI tools we've all come to know and love. For me, that's subclipse and tortoise. However, when I tried to figure out how to get those two apps to merge with the new merge tracking, I got stuck. And that's the point of this post: how to use these two GUI tools to do merges from trunk to branch, with merge tracking, with svn 1.5 Tortoise Had I read the excellent Tortoise docs before I started, I wouldn't have struggled at all with this. But I'm a "jump right in" kind of guy, clicking buttons and banging on things. So after it wasn't braindead simple, I gave up and RTFM (after complaining a lot... that's how I roll).
  1. While in trunk, make your changes. Commit
  2. switch to your branch (using tortoise, subclipse, whatever)
  3. Using tortoise, right click on the project in question, select "Merge"
  4. Select "Merge a range of revisions" radio button
  5. in the "URL to merge from", enter the URL to your trunk
  6. Leave the revision range blank. This was the central problem I was having!
  7. Click Next
  8. Do a "Test Merge" to see what it will do. If you're comfy with that, click "Merge"
In retrospect, this is actually really obvious, so maybe I was just having a momentary lapse of common sense. Possibly being confronted with the "revision" box kept my brain in revision number mode. Although I do swear that I tried it without any numbers but got nothing in the test merge.... but anyways.... it's working now. Subclipse I upgraded to the latest Subclipse, which as of this writing is the 1.4 tree. I did a team -- merge, got the normal merge dialog, and couldn't figure out how to get it to do a simple SVN 1.5 merge. It requires revision numbers to work correctly. I was pretty surprised that the new merge tracking wasn't built in to subclipse. So, after complaining (see a pattern?), I joined the subclipse mailing list and posted it as a question. There, I learned that I wasn't missing anything, as I was with tortoise. This functionality is indeed not built into subclipse. However, it is available in the Collabnet Desktop. (for you fast-and-loose types, here's the update URL for eclipse 3.3: This is a free plugin that does not replace subclipse but complements it. So I installed it, and now when I do a team -- merge from within Eclipse, I am confronted with a new set of screens. These screens walk you through doing a 1.5 style merge... Worked like a charm! So far, in my limited play with this, I havent hit any snags. Bottom line: subclipse doesn't do 1.5 merging, but the collabnet desktop will add this feature right into your existing subclipse 1.4 installation. One note: when I installed it in eclipse's update manager, I didn't hit any snags. But as with all things plugin related, your mileage may vary. Many, many thanks to the folks at Tortoise and Collabnet for the excellent work!


Jim Priest said...

Very interesting! I'll have to checkout this CollabNet Desktop. I wonder if they have plans for the future to roll this into Subclipse?

Marc Esher said...

in a different thread on the subclipse group, someone said "I wish they'd...." but it didn't get any response. In my thread Mark didn't say one way or another whether it would be integrated.

Indy Nagpal said...

I gave it a go a few weeks back and it did seem to perform well.

However, I am moving towards a more decentralized version control system now.

Subversion is nice, but with large number of files in a repo, branching is a big big pain.

Marc Esher said...

related to the merge tracking is the new "reintegrate" merge in SVN 1.5. I just tried it out using subclipse/collabnet desktop, and it's extremely cool.

Seth Bienek said...

Another great post Marc, thanks for sharing!

Anonymous said...

Nice article. Thanks.