Re: Confirming a merge

This is a multipart message in MIME format.
--=_alternative 0070407A85257237_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

I agree ... we made this change in JSR-170 (which otherwise follows the=20
RFC-3253 model).
If we do a maintenance release for RFC-3253, this is an enhancement we=20
should probably add.
Cheers,
Geoff




Werner Donn=E9 <[email protected]>=20
Sent by: [email protected]
12/01/2006 02:43 PM
Please respond to
[email protected]


To
[email protected]
cc

Subject
Confirming a merge







Hi,

To confirm a merge, a client should move a source URI from either
the merge-set or the auto-merge-set to the predecessor-set. This
can lead to an inconsistent server if the second of both property
updates fails or is never issued by the client. Such a responsibility
should not lie with the client. I think it is better that the server
does it and in an atomic way. This requires either another method
or another behaviour of the CHECKIN method when a merge is not
complete, i.e. the CHECKIN becomes the confirmation.

Regards,

Werner.
--=20
Werner Donn=E9  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803            e-mail: [email protected]



--=_alternative 0070407A85257237_=
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable


<br><font size=3D2 face=3D"sans-serif">I agree ... we made this change in J=
SR-170
(which otherwise follows the &nbsp;RFC-3253 model).</font>
<br><font size=3D2 face=3D"sans-serif">If we do a maintenance release for R=
FC-3253,
this is an enhancement we should probably add.</font>
<br><font size=3D2 face=3D"sans-serif">Cheers,</font>
<br><font size=3D2 face=3D"sans-serif">Geoff</font>
<br>
<br>
<br>
<br>
<table width=3D100%>
<tr valign=3Dtop>
<td width=3D40%><font size=3D1 face=3D"sans-serif"><b>Werner Donn=E9 &lt;we=
[email protected]&gt;</b>
</font>
<br><font size=3D1 face=3D"sans-serif">Sent by: ietf-dav-versioning-request=
@w3.org</font>
<p><font size=3D1 face=3D"sans-serif">12/01/2006 02:43 PM</font>
<table border>
<tr valign=3Dtop>
<td bgcolor=3Dwhite>
<div align=3Dcenter><font size=3D1 face=3D"sans-serif">Please respond to<br>
[email protected]</font></div></table>
<br>
<td width=3D59%>
<table width=3D100%>
<tr valign=3Dtop>
<td>
<div align=3Dright><font size=3D1 face=3D"sans-serif">To</font></div>
<td><font size=3D1 face=3D"sans-serif">[email protected]</font>
<tr valign=3Dtop>
<td>
<div align=3Dright><font size=3D1 face=3D"sans-serif">cc</font></div>
<td>
<tr valign=3Dtop>
<td>
<div align=3Dright><font size=3D1 face=3D"sans-serif">Subject</font></div>
<td><font size=3D1 face=3D"sans-serif">Confirming a merge</font></table>
<br>
<table>
<tr valign=3Dtop>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=3D2><br>
Hi,<br>
<br>
To confirm a merge, a client should move a source URI from either<br>
the merge-set or the auto-merge-set to the predecessor-set. This<br>
can lead to an inconsistent server if the second of both property<br>
updates fails or is never issued by the client. Such a responsibility<br>
should not lie with the client. I think it is better that the server<br>
does it and in an atomic way. This requires either another method<br>
or another behaviour of the CHECKIN method when a merge is not<br>
complete, i.e. the CHECKIN becomes the confirmation.<br>
<br>
Regards,<br>
<br>
Werner.<br>
-- <br>
Werner Donn=E9 &nbsp;-- &nbsp;Re<br>
Engelbeekstraat 8<br>
B-3300 Tienen<br>
tel: (+32) 486 425803 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
&nbsp; &nbsp; e-mail: [email protected]<br>
<br>
</font></tt>
<br>
--=_alternative 0070407A85257237_=--