In Common Use-Cases for Merging the first example looks like:
$ svn update
At revision 405.
$ svn merge -r 341:HEAD
http://svn.example.com/repos/calc/branches/my-calc-branch
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
http://svn.example.com/repos/calc/branches/my-calc-branch
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
1910.
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'?
Simon
---------------------------------------------------------------------
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