headers
Werner Donné | 20 Nov 2006 10:14
Picon

descendant-version postcondition of MERGE method


Hi,

What happens when the UPDATE method is not supported and when
the checkout-fork property of the checked-in version of the
merge target is "forbidden"?

Regards,

Werner.
--

-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne <at> re.be
Permalink | Reply | 1 comment |
headers
Manfred Baedke | 20 Nov 2006 11:23
Picon
Favicon

Re: descendant-version postcondition of MERGE method


Hi Werner,

I think this should be a 409 with 
DAV:checkout-of-version-with-descendant-is-forbidden.

Regards,
Manfred

Werner Donné wrote:
>
> Hi,
>
> What happens when the UPDATE method is not supported and when
> the checkout-fork property of the checked-in version of the
> merge target is "forbidden"?
>
> Regards,
>
> Werner.
Permalink | Reply | 0 comments |
headers
Werner Donné | 20 Nov 2006 11:57
Picon

Merging of collections


Hi,

RFC 3253 says that if the merge source identifies a VCR, the checked-in
version of that VCR is the merge source. This doesn't seem to cover
the classical case where a labeled version in one branch is merged into
another branch. Allowing the Label header in the MERGE method could
solve this. This way the request URI and the merge source could be the
same VCR, where the version with the label is the merge source.

Regards,

Werner.
--

-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne <at> re.be
Permalink | Reply | 1 comment |
headers
Werner Donné | 20 Nov 2006 12:46
Picon

report-properties postcondition of MERGE method


Hi,

What purpose does this feature serve?

Regards,

Werner.
--

-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne <at> re.be
Permalink | Reply | 1 comment |
headers
Werner Donné | 20 Nov 2006 15:40
Picon

Location header for MERGE method


Hi,

Why does the marchalling of the MERGE method say:

"The response to a successful request MUST include
a Location header containing the URL for the new
version created by the checkin."

The checkin of what?

Regards,

Werner.
--

-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne <at> re.be
Permalink | Reply | 1 comment |
headers
Geoffrey M Clemm | 20 Nov 2006 15:51
Picon
Favicon

Re: Merging of collections


Yes, that would be a reasonable optimization.  
Currently, that would require two round-trips ... one to retrieve the version with that label, and another to do the MERGE.

Cheers,
Geoff


Werner wrote on 11/20/2006 05:57:35 AM:
> RFC 3253 says that if the merge source identifies a VCR, the checked-in
> version of that VCR is the merge source. This doesn't seem to cover
> the classical case where a labeled version in one branch is merged into
> another branch. Allowing the Label header in the MERGE method could
> solve this. This way the request URI and the merge source could be the
> same VCR, where the version with the label is the merge source.

Permalink | Reply | 0 comments |
headers
Geoffrey M Clemm | 20 Nov 2006 15:56
Picon
Favicon

Re: report-properties postcondition of MERGE method


This allows the client to find out information about the resources in workspace that were modified by the MERGE.

Cheers,
Geoff

Werner wrote on 11/20/2006 06:46:08 AM:
> What purpose does this feature serve?
Permalink | Reply | 0 comments |
headers
Geoffrey M Clemm | 20 Nov 2006 15:58
Picon
Favicon

Re: Location header for MERGE method


That is a cut/paste bug ... that sentence should be deleted from the spec.

Cheers,
Geoff


Werner wrote on 11/20/2006 09:40:47 AM:
> Why does the marchalling of the MERGE method say:
>
> "The response to a successful request MUST include
> a Location header containing the URL for the new
> version created by the checkin."
>
> The checkin of what?

Permalink | Reply | 0 comments |
headers
Werner Donné | 1 Dec 2006 20:43
Picon

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

-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donne <at> re.be
Permalink | Reply | 1 comment |
headers
Geoffrey M Clemm | 1 Dec 2006 21:23
Picon
Favicon

Re: Confirming a merge


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



Werner Donné <werner.donne <at> re.be>
Sent by: ietf-dav-versioning-request <at> w3.org

12/01/2006 02:43 PM

Please respond to
werner.donne <at> re.be
To
 ietf-dav-versioning <at> w3.org
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.
--
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803                 e-mail: werner.donne <at> re.be


Permalink | Reply | 0 comments |

Gmane