AW: new conflict callback API

Hi, Stefan,

Von: Stefan Sperling [mailto:stsp_at_elego.de]
>
> On Wed, May 16, 2012 at 02:52:06PM +0100, Julian Foad wrote:
> > OK, I appreciate that issue. I see two ways the client lib can help:
> >
> > 1. providing a set of client-lib APIs to perform the most commonly
> > wanted resolutions;
> >
> > 2. providing a set of (APIs? comments?) that suggest what set of
> possible resolutions to offer for a given conflict.
> >
> > Does that match what you're aiming for?
> >
>
> Not quite. I am aiming for extensive coverage, not just the "most common"
> cases.
>
> The resolver should be good enough to handle any conflict people might run
> into, and offer all reasonable resolution strategies for a given conflict.
> We won't get there in one day, of course. It will evolve with time.
>
> There should be no reason for client UIs to implement custom resolution
> strategies. Any such strategies belong into the core. If UI developers
> have a special need they should talk to us and ask for a change in the
> resolver if need be. The current situation is too fragmented and
> confusing.

Hmm, this may lead to _very_ special strategies implemented in the core.

Like when a CoDeSys Device plugged into a Slot conflicts, and a neighbor slot is empty.

On the SVN Working copy, this looks like (irrelevant files and directories omitted):

Device (Device node directory)
+ svnobj (Data file of the Device itself)
+ [1] (Directory of Slot 1)
| + svnobj (Data file of Slot 1, containing plugged device)
+ [2] (Directory of Slot 2)
   + svnobj (Data file of Slot 2, containing an empty slot)

Now the conflict can be either a "normal" conflict of Device/[1]/svnobj, or an "incoming addition and local addition" tree conflict on the Device/[1]/ directory (Maybe after resolving a similar conflict on the Device parent directory).

I can offer the user the following two possibilities (amongst others):
1) Move the existing device to the neighbor slot, so the slot is free for the incoming device.
2) Redirect the incoming device to the neighbor slot.

For resolution 1, I need to:
- remove Device/[2]/svnobj
- move Device/[1]/svnobj to Device/[2]/svnobj (retaining history)
- resolve the conflict of Device/[1] using "theirs".

For resolution 2, I need to:
- remove Device/[2]/svnobj
- "redirect" the incoming version of Device/[1]/svnobj to Device/[2]/svnobj.
   (My current strategy to achieve this is:
    - first move Device/[1] into a "backup" location
    - then resolve using "theirs"
    - then move Device/[1] to Device/[2]
    - and then restore the old Device/[1] from the backup location.

For our part, we're not interested in the history of directories as such at all (except that the're part of the path of the file), only the data files and their properties are of interest, and those have their very own structural semantics and constraints.

> I don't think it helps our users if every client developer keeps
> reinventing the wheel. That just leads to inconsistent behaviour and
> indicates a deficiency of the core library.

This will work fine for "most" clients, where I define "most" as those simply working on a directory tree, and then the build toolchain / compiler / IDE / whatever has to cope what is in the directory tree.

For clients which version something else (like the CoDeSys object database) which has their own structure and constraints, the semantic translation needed between that "something else" and the directory tree may prohibit some ways of conflict resolution, while offering some new ones on the other hand.

> So, the APIs should present the supported options, and then act upon the
> choice made by the user. I don't see why you would want to split these
> APIs into two separate categories. They belong together.
>
> As I mentioned, if clients still want to mess with conflicts on their own
> using any of the existing APIs, they can do so. We won't force client API
> users to run the resolver, just strongly encourage them to do so.
>
> Note that all of this will run during an offline resolve, *not* during the
> current interactive conflict resolution during update/merge.
> I intend to remove interactive conflict resolution during update/merge for
> 1.8 and make 'svn resolve' handle all conflict resolution instead (at
> least to the same degree as interactive conflict resolution in 1.7, if not
> better).

Best regards

Markus Schaber

-- 
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com 
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915