A client asked me today about how to most effectively merge his changes from trunk to a production tag (in his case, tags/prod within his subversion repository).

The problem with merging two non-working copies in this case is that each one is about 54 megs of data. All in all, with the roundtrip to the server (twice!), the merge was taking about 45 minutes to complete.

The alternative is to do a “working copy” merge, where you merge between two working copies, back to the first one, like so:

• trunk - source working copy
• tags/prod - destination working copy

However, when you try to run svn merge as such:

svn merge trunk tags/prod

You’ll end up with a clever and not-so-helpful error as such:

svn: A working copy merge source needs an explicit revision

So okay, we need to specify working copy revisions. What the heck are they?

When doing an svn info on the prod tag we get:

svn info tags/prod

The item above that’s of interest is “Last Changed Rev” which we can use in the working copy merge.

We can then rewrite the above svn merge command as follows:

svn merge -r 292:HEAD trunk tags/prod

The amount of forensic work needed in order to get to this result is a bit silly, so to shortcut it a bit, I’ve created a quick script to do the same thing in a more automated fashion. Just save the script below as svnmerge_prod.sh in your path and chmod it to u+x.

(note this only works on unix variant systems, e.g. Linux or OSX.. Windows users, you’re on your own, I’m afraid):

DRYRUN="" if [ "x$1" == "--dry-run" ]; then DRYRUN="--dry-run" fi PRODREV=$(svn info tags/prod | grep "^Last Changed Rev:" | awk '{print $4}') svn $DRYRUN merge -r $PROD_REV:HEAD trunk tags/prod

Then change to your working copy directory (the one with both the trunk and tags directory in it), and run the script, e.g.:

~/bin/svnmerge_prod.sh

Note that you can pass —dry-run as an argument to this script to see what it will do before it does it.

Make sure to svn commit after you do the merge, and you should be all set to go!