On Tue, Jun 29, 2010 at 6:56 PM, Tino Schwarze <subversion.li...@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.