W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > July to September 2008

AW: Conflict detection in DeltaV using ServerSide Workspace

From: <M.Jung@dlr.de>
Date: Fri, 4 Jul 2008 13:31:39 +0200
Message-ID: <EA5B35EEE31E4B4E89473B9EA0905C4D9A03A8@exbe02.intra.dlr.de>
To: <tim@brooklynpenguin.com>
Cc: <ietf-dav-versioning@w3.org>

So here is my next approach to detect conflicts on server-side;-)

- the server allows checkout-fork 
- checkin-fork will always be forbidden. (See chapter 11.7.2 in in Dusseaultīs book)

The client creates a private activity and does a “checkout” of his files to the activity. Furthermore the client adds a “apply-to-version” element inside the checkout request. This turns the VCR in a “Working Resource” so that every client has its own working copy.

Now we come to the conflict detection:

When the client “checkin” the activity, all his private working resources will be automatically checked-in by the server. When someone else already changed and checked in a VCR that is in our activity (a conflict) the server will see, that the predecessor-set to what our working resources points to, already has a successor. In this situation the server normally has to do a fork. Checkin-fork is forbidden by the server so the server return an errors message.

Is this a possible approach?

Thanks for your answers :-)

Received on Friday, 4 July 2008 11:34:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:49 UTC