Conflict detection in DeltaV using ServerSide Workspace

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Conflict detection in DeltaV using ServerSide Workspace

M.Jung

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?


Thank you for your Help.

Best regards

Martin


--
Martin Jung
master student

DLR (German Aerospace Center),
Simulation and Software Technology
Linder Hoehe, 51147 Cologne, Germany

eMail: m.jung at dlr.de http://www.dlr.de/sc


Reply | Threaded
Open this post in threaded view
|

Re: Conflict detection in DeltaV using ServerSide Workspace

Geoffrey M Clemm

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


[hidden email] 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?
Reply | Threaded
Open this post in threaded view
|

RE: Conflict detection in DeltaV using ServerSide Workspace

M.Jung

Hello Geoff,

> -----Original Message-----
> From: Geoffrey M Clemm [mailto:[hidden email]]
> Sent: Tuesday, June 24, 2008 5:19 PM
> To: Jung, Martin
> Cc: [hidden email]; [hidden email]
> 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
>
> [hidden email] 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?


Reply | Threaded
Open this post in threaded view
|

Re: Conflict detection in DeltaV using ServerSide Workspace

Tim Olsen-5
In reply to this post by M.Jung

On Tue, 24 Jun 2008 13:11:02 +0200
<[hidden email]> wrote:

>
> 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?

yes, a checked out VCR will have a DAV:predecessor-set.  Depending on
the value of DAV:checkin-fork, the server may or may not fail a CHECKIN
in your situation.  In particular, see the
DAV:checkin-fork-forbidden and DAV:checkin-fork-discouraged
preconditions for CHECKIN in 4.4 of the RFC.

If CHECKIN fails due to one of these preconditions, the client can then
use the MERGE method to alter the DAV:predecessor-set of the checked-out
VCR and then you can try the CHECKIN again.

Cheers,
Tim

Reply | Threaded
Open this post in threaded view
|

Re: Conflict detection in DeltaV using ServerSide Workspace

Tim Olsen-5

On Wed, 25 Jun 2008 10:47:51 -0400
Tim Olsen <[hidden email]> wrote:
> If CHECKIN fails due to one of these preconditions, the client can
> then use the MERGE method to alter the DAV:predecessor-set of the
> checked-out VCR and then you can try the CHECKIN again.

Actually, you can alter the DAV:predecessor-set directly using
PROPPATCH.  MERGE handles multiple files better though.

For a good discussion about these issues see 11.7 in Dusseault's book.
In particular, see 11.7.3 - 11.7.5

-Tim

Reply | Threaded
Open this post in threaded view
|

Re: Conflict detection in DeltaV using ServerSide Workspace

Geoffrey M Clemm
In reply to this post by Tim Olsen-5

I agree with Tim's comments below.  Another approach that is commonly used is to allow the CHECKIN in a private workspace to succeed and create forks in the version tree, and have a separate server-side "integration workspace" to integrate the work being done in the private workspaces.  In particular, when an author is ready for the other team members to see his work, he would MERGE his private workspace into the integration workspace.  If there are any conflicts, those will identified in the response of the MERGE request.  If the chance of conflicts is high, or if the resolution of the conflicts is likely to take a while, a variant of this approach is to first perform a MERGE (a "merge-in") from the integration workspace into the private workspace, resolve any conflicts there, and then do a MERGE (a "merge-out") from the private workspace into the integration workspace with "DAV:NO-CHECKOUT" specified in the MERGE request.  This ensures that the integration workspace is never left in a "partially merged" state (i.e. where there are checkouts in the integration workspace resulting from conflicts).

Cheers,
Geoff

> On Tue, 24 Jun 2008 13:11:02 +0200
> <[hidden email]> wrote:
> > 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?


Tim Olsen wrote on 06/25/2008 10:47:51 AM:
> yes, a checked out VCR will have a DAV:predecessor-set.  Depending on
> the value of DAV:checkin-fork, the server may or may not fail a CHECKIN
> in your situation.  In particular, see the
> DAV:checkin-fork-forbidden and DAV:checkin-fork-discouraged
> preconditions for CHECKIN in 4.4 of the RFC.
>
> If CHECKIN fails due to one of these preconditions, the client can then
> use the MERGE method to alter the DAV:predecessor-set of the checked-out
> VCR and then you can try the CHECKIN again.

Reply | Threaded
Open this post in threaded view
|

AW: Conflict detection in DeltaV using ServerSide Workspace

M.Jung
In reply to this post by Tim Olsen-5

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

Preconditions:
- 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 :-)

  Martin