On Tue, Jun 29, 2010 at 6:56 PM, Tino Schwarze <subversion.lists_at_tisc.de> wrote:
> Hi Olivier,
>
> On Tue, Jun 29, 2010 at 10:18:31AM +0200, Olivier Sannier wrote:
>
>>> I've had a discussion with a collegue yesterday and he wondered why
>>> --reintegrate is neccessary for reintegration merges at all. He supposed
>>> SVN should be able to determine that the intended merge is a reintegrate
>>> by looking at the mergeinfo.
>>>
>>> So, this is just a question out of curiousity: Why is it neccessary to
>>> specify --reintegrate? Or: In which case would a potential
>>> auto-detection fail?
>
>> As always, the book is here for you:
>>
>> http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate
>
> I read that, but failed to understand why the mergeinfo-Properties set
> on the branch do not suffice to figure out what to reintegrate...
The critical paragraph is this one:
"When merging your branch back to the trunk, however, the underlying
mathematics is quite different. Your feature branch is now a mishmosh
of both duplicated trunk changes and private branch changes, so
there's no simple contiguous range of revisions to copy over. By
specifying the --reintegrate option, you're asking Subversion to
carefully replicate only those changes unique to your branch. (And in
fact, it does this by comparing the latest trunk tree with the latest
branch tree: the resulting difference is exactly your branch
changes!)"
> Given a very simple repo with three revisions like that:
>
> /trunk/file (r2)
> /branch/bla/file (r4, mergeinfo in r3: Merged /trunk/@1-2)
>
> If I ran "svn merge /branch/bla" it's possible to detect that r3 is the
> result of a merge, so only r4 needs reintegration into trunk.
Actually, I think if you ran that at the moment, r3 would still try to
be merged back into trunk (and conflicts would result). I could be
wrong.
> Note that I'm not questioning the existence of the --reintegrate option,
> I just want to understand the particular case which made it neccessary
> in the first place.
>
> Thanks,
The problem comes where the actual contents of the merge revision (r3)
does not equal the original revision contents (r1-2), most often due
to merge conflicts. I can't think of an example off the top of my
head, but it certainly does happen.
Cheers,
Daniel B.
Received on 2010-06-29 11:20:07 CEST