Peter Lundblad wrote:
> Blair Zajac writes:
> > I'd like to put on the radar screen that whoever is the release/merge manager
> > for our 1.4.x branch should probably use some merge tracking tool to manage
> > revisions merged from trunk into the branch. I would also like to propose using
> > the svnmerge.py currently located in contrib/client.
> What are the benefits of using a merge tracking tool on a release
> branch? The most common operation on a release branch is to pick one
> or a few revision and merge them and be done with it. I thought merge
> tracking was more useful on feature branches and similar, but please
> enlighten me! :-)
Well, it gives several things:
1) Lists the revisions merged over. Can you easily tell me all the revisions
merged into 1.3.x? With svnmerge.py, you can say
$ svn pg svnmerge-integrated
Currently in 1.3.x, we don't keep the list since we remove the revisions from
the STATUS file.
2) Get a list of revisions that haven't been merged over yet.
$ svnmerge.py avail
3) Makes mistakes less likely. You don't have to worry about merging over a
revision you already merged over.
4) Generates a log message for 'svn commit -F' with the log messages that are
being merged over. So you can easily see in the merged log message what was
written about the original revision. You don't have to a svn log in the release
branch, then copy the revision into a separate command for the log on the trunk.
It's nice if you're merging a number of revisions over.
5) Block particular revisions from ever being merged over. If there are one or
more revisions you definitely never want merged over, you can mark them as such.
6) Handles multiple revisions easily:
In the svnmerge.py case, I had over 27 revisions to propose for merging from
trunk to 1.3.x. With svnmerge.py, you can say
$ svnmerge merge -r
and it'll automatically consolidate revision ranges and do the merge for you.
I just find it easier to work with. At work, we have a project with 1.0, 1.1
and 1.2 release branches. The three branches were created in the last months,
as the project is seeing fast moving development for an internal client. All
changes occur on trunk and then are chosen for merging to one or more release
branches. It saves much of the hassle of putting multiple svn commands.
Granted, while you can get all the work done without the tool (as it only uses
the svn command line tool to do its work), it does make life easier. I would
recommend people give it a try on their next release branch.
Blair Zajac, Ph.D.
Subversion training, consulting and support
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Mar 1 20:41:48 2006