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.
Received on 2012-03-23 20:00:26 CET