Re: Conflict detection in DeltaV using ServerSide Workspace

This is a multipart message in MIME format.
--=_alternative 00704A3085257473_=
Content-Type: text/plain; charset="US-ASCII"

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
> <[email protected]> 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.


--=_alternative 00704A3085257473_=
Content-Type: text/html; charset="US-ASCII"


<br><tt><font size=2>I agree with Tim's comments below. &nbsp;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
&quot;integration workspace&quot; to integrate the work being done in the
private workspaces. &nbsp;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. &nbsp;If there are any conflicts, those
will identified in the response of the MERGE request. &nbsp;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
&quot;merge-in&quot;) from the integration workspace into the private workspace,
resolve any conflicts there, and then do a MERGE (a &quot;merge-out&quot;)
from the private workspace into the integration workspace with &quot;DAV:NO-CHECKOUT&quot;
specified in the MERGE request. &nbsp;This ensures that the integration
workspace is never left in a &quot;partially merged&quot; state (i.e. where
there are checkouts in the integration workspace resulting from conflicts).</font></tt>
<br>
<br><tt><font size=2>Cheers,</font></tt>
<br><tt><font size=2>Geoff</font></tt>
<br>
<br><tt><font size=2>&gt; On Tue, 24 Jun 2008 13:11:02 +0200<br>
&gt; &lt;[email protected]&gt; wrote:<br>
&gt; &gt; I want to allow simultaneous editing of resources by multiple
users<br>
&gt; &gt; with WebDAV/DeltaV. For that, I use a ServerSide-Workspace for
every<br>
&gt; &gt; user. The user can &quot;check out&quot; a file in his private
workspace and<br>
&gt; &gt; work on it. After that, the user can &quot;check in&quot; all
of his files with<br>
&gt; &gt; the DeltaV activity feature. Now I am looking for a standard<br>
&gt; &gt; &quot;serverside&quot;-way to detect conflicts when both users
try to commit<br>
&gt; &gt; their changes on the same file. Is there any standard way to
detect<br>
&gt; &gt; these conflicts with WebDAV/DeltaV on serverside?</font></tt>
<br><tt><font size=2><br>
Tim Olsen wrote on 06/25/2008 10:47:51 AM:<br>
&gt; yes, a checked out VCR will have a DAV:predecessor-set. &nbsp;Depending
on<br>
&gt; the value of DAV:checkin-fork, the server may or may not fail a CHECKIN<br>
&gt; in your situation. &nbsp;In particular, see the<br>
&gt; DAV:checkin-fork-forbidden and DAV:checkin-fork-discouraged<br>
&gt; preconditions for CHECKIN in 4.4 of the RFC.<br>
&gt; <br>
&gt; If CHECKIN fails due to one of these preconditions, the client can
then<br>
&gt; use the MERGE method to alter the DAV:predecessor-set of the checked-out<br>
&gt; VCR and then you can try the CHECKIN again.<br>
<br>
</font></tt>
--=_alternative 00704A3085257473_=--