Branch Management with svnmerge
Document Actions
You can get svnmerge from the official source, or from
the Debian package subversion-tools. The Debian version is pretty old,
though, so I recommend getting the newest version from the website and
"installing" it in /usr/local/bin or something.
Read up on the project website, too, but here's the skinny: svnmerge
keeps track of the versions of some source already merged into a target. It
does this through a SVN property, but that doesn't matter so much. You can
ask it, once it's tracking this information, to merge some or all non-merged
versions of the source into the target branch. When it does this, it will
update its tracking of what's already merged. This is a lot easier than
always searching through the svn log for the last merge from trunk, or
even keeping up a tag of the last merge point as I suggested earlier.
Normally you start tracking a branch upon its creation, when it's equal to
the trunk, with a simple::
$ svnmerge init
It will record that all versions from 0 to now have been merged to this
branch. If you have a branch that has already been created (like the dozens
of plone25 branches) then you have to manually tell it the revisions
that have already been merged, namely 0 to the last time we merged from
trunk. Yes, this means
$ svn log --stop-on-copy | less
...but for the last time for the life of this branch.
So we find the last time we were synced with trunk (either creation or the
last merge from trunk) and initialize tracking with::
$ svnmerge init -r0-XXXXX
where XXXXX is the version we extracted from the log. The svnmerge command
is always meant to be run from the top of the working directory that is being
merged to, by the way. Then we commit the tracking changes, preferably along
with the helpful commit message svnmerge creates::
$ svn ci -F svnmerge-commit-message.txt
$ rm svnmerge-commit-message.txt
In other circumstances, the commit message becomes quite large, copying
the logs of all the merged changes. I don't know that we want to check those
in; it might be helpful, but I'm going to not do so for now.
Now that svnmerge is tracking this branch, we can ask it what changes are
available on the source (trunk) to merge into this branch::
$ svnmerge avail
But usually we just want to merge all the new stuff from trunk, so we
say::
$ svnmerge merge
It will update the current working directory with the merged changes.
Examine the changes, resolve any conflicts, and then commit the changes,
which will update svnmerge tracking info. If there are no merged changes, you
don't have to do anything, of course.
Subsequent merges to that branch won't require so much work, just the last
steps of svnmerge merge, check the diff, and commit.
That's pretty nice, huh? It can also be used for merging branches to trunk,
using a similar technique, but the project site documents that nicely, and I
don't have anything to add, having not done it yet. It looks like it may be
slightly more typing than the traditional manner (merging to trunk is easier
in regular SVN than from trunk) but the bidirectional merge may have some
offsetting advantages.
I'm not going to require use of svnmerge everywhere just yet, just on
the plone25 branches, but I think anyone who will be doing branch
maintenance should try it out in order to be able to raise any objections to
doing so universally.
