Von: Stefan Sperling [stsp_at_elego.de]
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)
>> +  (Directory of Slot 1)
>> | + svnobj (Data file of Slot 1, containing plugged device)
>> +  (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//svnobj, or an "incoming addition and local addition" tree conflict on the Device// 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//svnobj
>> - move Device//svnobj to Device//svnobj (retaining history)
>> - resolve the conflict of Device/ using "theirs".
>> For resolution 2, I need to:
>> - remove Device//svnobj
>> - "redirect" the incoming version of Device//svnobj to Device//svnobj.
>> (My current strategy to achieve this is:
>> - first move Device/ into a "backup" location
>> - then resolve using "theirs"
>> - then move Device/ to Device/
>> - and then restore the old Device/ 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.
If the set of built-in strategies will involve such strategies, then I'm fine with it, and I'll happily use such functionality.
Especially some standard way to "redirect" the incoming conflict candidate to a different local location (recording it as a local move / rename) would be appreciated. AFAICS, this is not offered yet by the SVN libraries, but would also potentially help "normal" users.
> 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.
It is implemented prototypically, but not yet in the released versions.
And I know that the old way of resolving conflicts after the update operation will continue to happen.
I just wanted to show that there might be some strategies employed by clients which may seem very special. If you do not regard those strategies as special, and will include them in the default set of available operations, fine. I won't complain then, but happily use them once released, and enjoy the simplification of my code.
>> > 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.
Yes, I guess what we're doing is out of scope of SVN, but I think it also is out of scope for most other version control systems.
So the only possibility for us is to build a mapping layer between the database and a file/directory hierarchy, and then use some VCS for files and directories.
At the end, I don't see the semantical difference to "classical" systems to be that big. It is only that, after some operations, the user is responsible for repairing the "damage" in the working copy, when Visual Studio / Eclipse & Co bark on what they find in their directory trees.
Received on 2012-05-17 09:20:51 CEST