Re: Merging of collections

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

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.


--=_alternative 0051CCFF8525722C_=
Content-Type: text/html; charset="US-ASCII"


<br><tt><font size=2>Yes, that would be a reasonable optimization. &nbsp;</font></tt>
<br><tt><font size=2>Currently, that would require two round-trips ...
one to retrieve the version with that label, and another to do the MERGE.</font></tt>
<br>
<br><tt><font size=2>Cheers,</font></tt>
<br><tt><font size=2>Geoff</font></tt>
<br>
<br>
<br><tt><font size=2>Werner wrote on 11/20/2006 05:57:35 AM:<br>
&gt; RFC 3253 says that if the merge source identifies a VCR, the checked-in<br>
&gt; version of that VCR is the merge source. This doesn't seem to cover<br>
&gt; the classical case where a labeled version in one branch is merged
into<br>
&gt; another branch. Allowing the Label header in the MERGE method could<br>
&gt; solve this. This way the request URI and the merge source could be
the<br>
&gt; same VCR, where the version with the label is the merge source.<br>
<br>
</font></tt>
--=_alternative 0051CCFF8525722C_=--