On Wed, May 16, 2012 at 02:52:46PM +0000, Markus Schaber wrote:
> 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.
What is special about that?
Apart from terminology that is entirely foreign to Subversion, the above
example describes some possible strategies to resolve conflicts.
Do I understand correctly that you've already implemented the above
in your client? If so, whatever you've implemented will keep working.
It is not like a new resolver would break any of that.
> > 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.
Subversion versions files and directories. If your system requires
an abstraction that doesn't fit the files and directories concept,
you're way out of the intended scope of use anyway. If your conflicts
can be expressed in terms of file and directories the resolver can
support them. Else, you'll have to use something else to help users
of your product with resolving these conflicts.
Received on 2012-05-16 17:22:17 CEST