ch04: second merge example misleading?

David Boyce david.boyce at ticketmaster.co.uk
Wed Oct 11 08:13:46 CDT 2006


Hi,

I was discussing branch merges with a colleague and he made a statement
about 
'adding one to the previously merged  revision' claiming that he'd read it
in
the manual.

This seemed strange to me, so I had a closer look at chapter 4 and concluded
that he's drawn this idea from the 'Merging a Whole Branch to Another'
section,
in particular the 'one week later' case where it says:

<quote>
Aha!  Since all branch-changes that happened between revisions 341 and 405
were
previously merged to the trunk as revision 406, you now know that you want
to
merge only the branch changes after that-by comparing revisions 406 and
HEAD.
</quote>

At the risk of challenging a long-term part of the documentation and being
wrong,
I think this is based on a faulty assumption: that the branch is inactive
between
the merge of the branch's 341:405 into the trunk and the commitment of the
trunk
merge (as r406).  

Obviously, in the case stated, there can have been no activity, but this is
an
artifact of the example rather than always true.  Consider if another
developer
had checked in changes to the branch as r406 instead, while the 341:405
changes
were committed to the trunk as r407.  On the above wording, the r406 change
would
not be included in the later merge (because the merge would be 407:HEAD).
 
If you agree that this is incorrect, I would like to suggest a slight
modification
of the wording along the following lines:

<suggested text>
Aha!  Since all branch-changes that happened between revisions 341 and 405
were
previously merged to the trunk (as revision 406), you now know that you want
to
merge only the branch changes after that - by comparing revisions 405 and
HEAD.
</suggested text>

and modifying the following code example accordingly (changing 406 to 405 in
a
couple of places).

All this is based on the understanding that in the form of the svn merge
command

          svn merge -r N:M SOURCE[@REV] [WCPATH] 

the 'diffs' are generated by comparing the revisions at the URL derived from
SOURCE,
and that revisions within that range which aren't updates to the part of the
repository specified by URL are irrelevant.

David Boyce

These are my own views, not necessarily those of my employer!




More information about the svnbook-dev mailing list