Re: Conflict detection in DeltaV using ServerSide Workspace

A given file can only have one checkout in a given workspace.
So if user A checks out a file in the server-side workspace, an attempt by 
user B to checkout that same file in that same workspace will fail (with 
an "already checked out" error).

If you want to use a single server-side workspace for all the users, you 
would not register the checkout on the server.  Instead, the client for a 
given user would GET the files that the user wants, and remember what 
versions of those files it downloaded..  When the user tries to "checkin" 
a change, the client would attempt to checkout the file, and retrieve the 
CHECKED_OUT version property.  If the CHECKED_OUT version was the same as 
the one the client originally downloaded, the client can just PUT the new 
content, and CHECKIN.  If the CHECKED_OUT version is different, the client 
would have to notify the user that a "merge conflict" has occurred, peform 
a merge of the users version with the CHECKED_OUT version, and then 
checkin the results of the merge.

Cheers,
Geoff 

ietf-dav-versioning-request@w3.org wrote on 06/24/2008 07:11:02 AM:

> 
> Hello,
> 
> I want to allow simultaneous editing of resources by multiple users with
> WebDAV/DeltaV. For that, I use a ServerSide-Workspace for every user.
> The user can "check out" a file in his private workspace and work on it.
> After that, the user can "check in" all of his files with the DeltaV
> activity feature. Now I am looking for a standard "serverside"-way to
> detect conflicts when both users try to commit their changes on the same
> file. Is there any standard way to detect these conflicts with
> WebDAV/DeltaV on serverside?
> 
> My idea was (like in Subversion/mod_dav_svn), that the server keeps
> track of the revisions, that are in the private workspace of the user,
> to detect conflicts. 
> 
> Here you can see a sequence diagram that illustrates the operations. 
> 
> http://www.haifischmade.de/apache2-default/seqConWebDAV.jpg
> 
> User A and user B check out the file Foo. The server keeps track that
> they both checked out version 1 of the file Foo. Now both users start to
> edit the file in their own workspace. Then user A finishes editing and
> checks in his workspace (ActivityUserA). Now the server increments the
> version of file Foo up to 2. Now user B wants to check in his file, but
> the server recognizes that UserB has changed the file based on version 1
> and so the server rejects the check in. 
> 
> Is this the right way?