Hi there,
I need to followup on this quite old thread... I've not yet groked it.
:-(
On Tue, Jun 29, 2010 at 07:18:07PM +1000, Daniel Becroft 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!)"
The last sentence doesn't make sense to me. It would require me to merge
all changes from trunk into the feature branch before reintegration?
Otherwise, my feature branch would undo everything not merged from trunk
(because of that latest tree comparison)?
I've read the section about merging again and the above seems to be
true.
Therefore, we'd need to ensure (by organizational process) that nobody
checks in anything into the trunk while the feature branch is being
tested for reintegration or these additional changes will get lost?
> > 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.
I gather it would be rather difficult for Subversion to figure out which
revision in the branch contains which changes from trunk (it would need
to figure out which revision added the appropiate revisions to the
mergeinfo property).
Thanks,
Tino.
--
"What we nourish flourishes." - "Was wir nähren erblüht."
www.tisc.de
Received on 2010-09-23 14:24:29 CEST