Send As SMS

Wednesday, March 15, 2006

Grafting in SVN

SVN is a pretty good tool on the whole, but sometimes too much thinking is required.

I had a branch created a while back that needed to use work that I'd merged into the trunk since creating the branch. If I was feeling particularly brave I'd try merging the changes back into my branch and hoping that the merge algorithm would work it all out correctly. I'm not yet that brave.

What I did decide to do was to commit all changes to my branch, delete it, rebranch from the current trunk and then merge the previous changes, confidently assuming that the semantics of SVN's merge are such that this would be a reliable operation and that conflicts would be reported immediately (rather than at eventual merge time, had I chosen to attempt to merge the concurrent changes back into the existing branch).

The assumption was correct, but there were some pitfalls. The final commands were
svn copy -q http://server/repos/trunk http://server/repos/branch -m "comment"

svn co -q http://server/repos/branch

cd branch

svn merge -r 4028:4109 http://server/repos/branch@4028

The magic revolves around those two numbers (4028, 4109) and, in particular, remembering to append @4028. I forgot the latter for the first 30 minutes of struggling with this. I did on some previous occasion get my head around the reason for this appending, but the details escape me at this moment. So:
  • 4028 was the revision at which the branch was previously created using "svn copy". This is most easily discovered with "svn log --stop-on-copy" before deleting and re-creating the branch (because stop-on-copy will then be useful), but can readily be discovered through browsing a much longer log afterwards.
  • 4109 was the revision of the last commit to the branch before the delete (deletion occurred at 4110).
That's all there was to it. Next time...