On Fri, Mar 16, 2012 at 12:07, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> Here is what I'd like to see.
>
> We choose some default behaviour, but we
> don't hard-code the default behaviour. At the API level the behaviour should be
> controlled by flags or callbacks or what have you. At the UI level,
> just as we allow the user to plug in a 3-way merge tool for text merging if they don't like the default behaviour, so we should allow
> customization of tree-change merging. That could be just an option to
> select between two or thee modes ('strict', 'lax' or 'typical') or a UI
> giving more detailed control.
Sure. I identified two possible resolutions else-thread. We could
apply either one of those at 'svn update' time, and then allow the
conflict resolution to leave it as-is, or to choose the other
resolution. (or one of N, if there are more than two).
> Somebody mentioned months ago that the code would be cleaner if we would consistently treat every incoming change the same way. First store the incoming change, whatever it is, alongside the existing local change;
Yeah, we've talked about this quite a bit. I believe when you run 'svn
update', then BASE should precisely match the repository. Any local
modifications are then manipulated to be in terms of that new BASE.
The local-mod may be incompatible with the new BASE, so a conflict is
stored.
> then run a standard "conflict resolver callback" on it which in most cases would notice it's a trivial case and silently select the obvious resolution; and in any non-trivial case get the user's input.
Note: this resolve step would occur *after* the entire 'svn update'
completes. Whether that is some kind of callback or inspection API, or
whatever... we want to run it as "step two". The current interactive
resolution model means that a user could take so much time, that the
network connection drops due to timeout (bad!). By completing the
update, we would ensure that never happens.
This *should* be possible since it would look exactly like the user
said "postpone" at every interactive prompt. Our data model should be
able to record every possible conflict, then go and resolve them in a
second pass.
As you state: the UI could auto-resolve some, it could prompt for a
simple "yes" for the default case, or it could allow for more complex
queries/resolutions. But it does seem to be proper to push that out of
the update process and into a "resolve everything" pass.
> Then if the user wants all edit-vs-move potential conflicts to be resolved automatically, the user simply switches on the appropriate flag in the callback's baton by ticking a box in the GUI or passing a command-line option.
>
> Then selection of a default behaviour becomes an almost orthogonal discussion with zero impact on the svn library implementation.
Sure.
I mentioned two resolutions for a edit-source/move conflict:
1) update source to rN. rewrite move to source_at_N. apply changes to
move-dest, too. (Stefan's preference)
2) update source to rN. change move to a copy.
The update process could leave the working copy in *either* state,
record the conflict, and then resolution could choose the other state.
Choosing #1 as the state seems to have resounding support, so we go
with that. "Most users" would choose to just accept that state. But
they *would* have a resolve step where they could choose #2, and we
rejigger the working copy to make it happen.
Cheers,
-g
Received on 2012-03-16 17:23:14 CET