[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[BOOK] More comments on merging

From: Simon Large <slarge_at_blazepoint.co.uk>
Date: 2005-01-19 10:58:58 CET

In Common Use-Cases for Merging the first example looks like:

$ svn update
At revision 405.

$ svn merge -r 341:HEAD

In this particular case there will probably be no-one else working on
the branch, but in the general case using rev:HEAD as a source range
might have undesired effects if someone else were to commit a change to
the branch between the update and the merge. To be more consistent with
the commit comment on the next line it should be:

$ svn merge -r 341:405

When merging a feature branch, the problem is more acute because it is
possible that someone else will commit a change to trunk just before I
do my merge. The commit will then fail due to out-datedness, and when I
update I will get a conflict (or at least confusion) where my merge
removed the latest trunk change and the update put it back in again.

The worked example for a feature branch is correct in using a specific
revision for the tree compare, but it doesn't say _why_ it is doing
that, and the description just afterwards refers to HEAD and not rev

The chapter 9 reference section for svn merge makes no mention, and the
default revision is always HEAD anyway. Given that it is down to the
user to track precisely which revs have been merged, there is probably a
good case for never using HEAD for merging.

Should there be something in 'best practice'?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 19 10:58:57 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.