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

RE: Conflict detection in DeltaV using ServerSide Workspace

From: <M.Jung@dlr.de>
Date: Wed, 25 Jun 2008 14:14:37 +0200
Message-ID: <EA5B35EEE31E4B4E89473B9EA0905C4DA4C2D4@exbe02.intra.dlr.de>
To: <geoffrey.clemm@us.ibm.com>
Cc: <ietf-dav-versioning@w3.org>

Hello Geoff,

> -----Original Message-----
> From: Geoffrey M Clemm [mailto:geoffrey.clemm@us.ibm.com]
> Sent: Tuesday, June 24, 2008 5:19 PM
> To: Jung, Martin
> Cc: ietf-dav-versioning@w3.org; ietf-dav-versioning-request@w3.org
> Subject: 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).

Thanks for your fast response. I think my description was somewhat
misleading. My intention was to provide each user with his own private
server-side workspace where he can "check out" the files he wants to
work on. Maybe I try to achieve this with the "working
resources"-feature. But for that I will first study the docs [0,1] so
that I hopefully have a working "server side conflict detection model"
next week :-). 

BTW my primary goal is to model a set of WebDAV-operations as a
transaction. For that I want to user the "activity-feature" and server
side conflict detection.

Cheers,
Martin

[0] http://svn.collab.net/repos/svn/trunk/notes/webdav-general-summary
[1] L. Dusseault: WebDAV, Prentice Hall 2004

P.S. Do you have some additional references that might be insightful?
Besides the rfc of course ;)



> 
> 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?
Received on Wednesday, 25 June 2008 12:15:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 25 June 2008 12:15:40 GMT