[BOOK] More comments on merging

[Simon Large <sl...@blazepoint.co.uk>]

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

Re: [BOOK] More comments on merging

[Ben Collins-Sussman <su...@collab.net>]

Thanks, Simon.  I'll fix these things, I've made myself a note.


On Jan 19, 2005, at 3:58 AM, Simon Large wrote:

> 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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org