On Fri, Mar 16, 2012 at 04:07:50PM -0400, Greg Stein wrote:
> On Fri, Mar 16, 2012 at 15:04, Stefan Sperling <stsp_at_elego.de> wrote:
> >...
> > We perform the automatic merge *and* flag an "incoming edit vs. local move"
> > tree conflict. This alerts the user but makes it easy to fix the conflict
> > in the case where the incoming edit should be kept -- just mark as resolved.
>
> This would be great. As you point out: very easy to resolve. It also
> starts people on the path to recognize the inherent conflict and
> acknowledging its resolution, even if that to typically accept the
> suggestion.
But note again that this conflict is only an extra attention flag.
The update already clearly displays that it changes the file.
> If users provide feedback of "that's really annoying", then we can add
> a knob :-(
I think you're too worried about what users expect. Most users won't
care very much about details like this. Rather, they expect us to make
Subversion do something sensible in a given stituation, and they will
adapt their workflow to whatever Subversion does.
I expect people will quickly get used to the fact that edits follow
moves in Subversion 1.8. I'd be surprised if we get even a single
complaint about this from users.
> Personally, I'd be surprised if an edit/move conflict is all that
> common. Maybe you/others have some data on this? More prevalent in
> larger teams? Remote uncoordinated teams?
We don't really know. But there are some stereotypes that rename
often, and some that never rename.
A Java developer with an IDE that has a "Refactor" button will tend to
rename often. People who write drivers for embedded devices usually
do not ever rename anything.
Those are the two extremes I've encountered among people who attend
workshops at elego. I suppose there is a lot of middle ground though.
> > Because the auto-merge can cause text conflicts we'd need to add support
> > for flagging both a tree conflict and a text conflict on the same node.
> > Which AFAIK is not supported at the moment.
>
> To clarify my understanding: this is only necessary if we choose the
> above option? In "today's" code, it may flag a text conflict, so
> adding the capability for a edit/move conflict is additional work?
Yes, this would require additional work. The code today doesn't record
a tree-conflict. It just forwards the edit to the moved-to location.
Flagging a tree conflict would require some work to ensure that the
tree conflict and any potential text conflicts will peacefully coexist.
> > Overall, I'd still prefer to keep this as it is.
> >
> >> The former is "no more work",
> >> but does it paint us into any sort of corner to do this Right later?
> >
> > In some future release, the default behaviour will be prompting.
> > We could make the auto-merge behaviour available without prompting
> > if the user passes --accept=mine-conflict, meaning "keep my rename
> > but apply incoming edits to it". And --accept=mine-full could map
> > to "keep my rename and do not apply incoming edits to it".
> > In turn, the --accept=theirs-* options would undo the local rename,
> > the idea being that the resulting state should match "their" version
> > as closely as possible.
>
> Ugh. "theirs" and "mine" is really poor terminology, which is
> especially evident as you attempt to contort them into some kind of
> meaning above :-P
Yeah, it's not perfect. The terminology makes sense for diff3
conflicts and that's OK because that's what it was designed for.
Tree conflict resolutions aren't as easy to categorize.
>... I'd suggest that we have
> --accept=token1,token2,token3 ... where the tokens describe which type
> of resolution to perform. AFAIK, commas are not allowed in --accept,
> so this would be forward-compatible. In your above scenario,
> --mine-full is not "full" as it needs to switch your move into a copy,
> and reinstall the (updated) move-source. That's why I don't like
> trying to fudge resolutions into a limited set of names. We kind of
> end up back in the --force fiasco :-)
A multi-option UI like this requires the user to anticipate the possible set
of conflicts. I doubt people would put that much thought into typing an
'svn update' command line, even when writing scripts.
With tree conflicts, if the options map to approximate "keep my change"
or "keep their change" semantics, that's good enough. These options
cannot offer fine-graind control. They're just hints.
The real deal will of course be an interactive menu. Most people won't
specify an --accept option anyway and just use interactive prompts.
Received on 2012-03-17 01:33:46 CET