Re: Updating local-moves (was: svn commit: r1301390 ...)

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.

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; 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.  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.

- Julian
Received on 2012-03-16 17:08:32 CET