On Fri, Mar 23, 2012 at 10:55:45AM -0700, Mike Dixon wrote: > On 3/22/2012 10:19 PM, Branko Čibej wrote: > >On 22.03.2012 22:33, Julian Foad wrote: > >>Branko Čibej wrote: > >>>I'm confused. What additional checks would --reintegrate do that your > >>>common or garden merge would skip? What kind of check do you think you > >>>can safely skip without throwing all the effort you're putting into > >>>fixing the merge algorithm out the window? > >>The checks of target WC state mentioned above. Of course, the name > >>"reintegrate" would then be less than appropriate, and we could consider a > >>new name that makes more sense for that "I expect this to be a clean simple > >>merge" kind of meaning. Is the use of an asymmetric-sounding option name > >>for a now-symmetric functionality what was making you uncomfortable? > > > >No, what bugs me is the assumption that the user gives a pig's ear about > >whether the merge is "clean and simple" or whether the merge algorithm > >has to figure out all sorts of cherry picks and criss-cross twists. I > >very strongly suspect that the user doesn't care, she just wants merge > >to do the right thing, every time. What do you want --reintegrate to do, > >abort the merge if the user is wrong about "clean and simple?" Of course > >not. > > Hello, I'm a user. If I'm trying to bring a feature branch back onto > trunk and the merge isn't "clean and simple", 99% of the time it's > because I did something wrong. Either my working copy is in a > different state than I think it is, or the branch in a strange state > because of previous mistakes. It's nice that svn will be able to > handle more complicated merges in the future, but please don't > remove the existing checks on standard operations that protect me > from my own ignorance. > > I'm also the svn administrator at $WORK, and I can promise you that > my other users understand the system even less well than I do. I'm > not really looking forward to having to disentangle a reintegrate > that was applied to a WC with switched subtrees.
We went one step into this direction in Subversion 1.7. Merges into mixed-revisions working copies are disallowed by default in 1.7. The --allow-mixed-revisions option was added to allow users to override this check. I agree that we should make the checks that --reintegrate performs in Subversion 1.7 standard for all merges in Subversion 1.8. So there would be --allow-switched-subtrees, and --allow-local-mods options for 'svn merge', and by default any merge into a working copy with mixed-revisions, switched-subtrees, or local modifications would be disallowed. It is quite possible that some users would prefer to be able to merge into a working copy with local modifications by default, however. But disallowing switched subtrees by default definitely makes sense.
