I am very happy with Subversion as far as version control systems go, but it has one glaring deficiency. When you create branches, it can be extremely difficult to keep track of which changes you’ve merged from one branch to another. This is probably best explained with an example.
Let’s say you have a repository, and it’s setup with trunk
(where the main development takes place), branches
where you work on versions of the code separate from the trunk, and tags
, where you mark development milestones. One common development model for Web applications is to work on new features in the trunk and create a branch for the version of the application that’s actually deployed. You create that branch like this:
svn copy http://sourcecode/svn/myapp/trunk http://sourcecode/svn/myapp/branches/production
Eventually you’ll make changes in the trunk that need to be applied to the branch as well. This is where Subversion falls short. It knows where the branch originated, but it doesn’t provide any way of keeping track of which changes in the trunk have been merged into the branch (or vice versa). Keeping track of this sort of thing by hand is incredibly painful, and it’s exactly the sort of thing computers are good at.
A couple of days ago I discovered svnmerge, which handles this problem rather nicely. It’s a Python script, so it works on just about any platform (as long as you have Python installed), and it uses Subversion properties for data storage. Subversion properties are stored in the repository, so you can share your merge information among multiple users.
When you create a new branch, you just run the svnmerge init
command. As the trunk changes, you can use the svnmerge avail
command to see which revisions have not yet been merged into that branch. To perform and log the merges, you use svnmerge merge
. (svnmerge will merge only the revisions you specify or all of the outstanding revisions.)
If you’re a Subversion user, I strongly recommend checking out svnmerge. The one question I haven’t figured out the answer to is whether svnmerge also keeps track of revisions to the branch that need to be merged back into the trunk, but I’ll get to it.
Note: SVK is another tool which provides this functionality (and a lot of other things). I haven’t had the chance to use it myself, but I hear good things.
Foo Camp angst
Another year, another bout of kvetching over the attendee list for O’Reilly’s Foo Camp. Before I get started, let me say that I have never been invited to Foo Camp, and even if I were invited I probably wouldn’t go because I never go to conferences of any kind.
Let’s say I’m throwing a party and I want for it to be fun for myself and for the guests. I’m going to carefully choose who to invite in order to create the best mix of personalities and conversations that I can. I’m probably not going to invite people that I know to hate each other. I’m certainly not going to invite anyone that I don’t like.
Foo Camp is O’Reilly’s party. The problem seems to be that this party has lots of well known attendees who document the parties they go to on their weblogs, which opens them up to criticism from people who don’t like the kind of party they’re throwing. BarCamp is a much more productive response than complaining about somebody else’s party.