Re: Conflict detection in DeltaV using ServerSide Workspace

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
> <M.Jung@dlr.de> 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.