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
