- While in trunk, make your changes. Commit
- switch to your branch (using tortoise, subclipse, whatever)
- Using tortoise, right click on the project in question, select "Merge"
- Select "Merge a range of revisions" radio button
- in the "URL to merge from", enter the URL to your trunk
- Leave the revision range blank. This was the central problem I was having!
- Click Next
- Do a "Test Merge" to see what it will do. If you're comfy with that, click "Merge"
Subversion 1.5 Merge Tracking
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).
Subscribe to: Post Comments (Atom)
6 comments:
Very interesting! I'll have to checkout this CollabNet Desktop. I wonder if they have plans for the future to roll this into Subclipse?
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.
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.
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.
Another great post Marc, thanks for sharing!
Nice article. Thanks.
Post a Comment