Re: DAV:cannot-copy-collection-version precondition for COPY

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

COPY has to obey the semantics defined for it by RFC-2518 (so that an=20
RFC-2518 client can interoperate with an RFC-3253 server), or must fail.
Since a collection version is a resource with no members, the result of a=20
successful COPY of a collection version would have to be the creation of a =

destination resource with no children.  Since this is unlikely to be the=20
behavior that a versioning client would want, the COPY request is defined=20
to fail.

Cheers,
Geoff


Werner wrote on 08/22/2006 04:24:25 PM:
> I thought that a version of a collection represented the state of
> that collection at a certain point. So the=20
version-controlled-binding-set,
> which is a collection version property, contains the binding names
> that correspond to the members of the collection at that version.
> If collection /a has members b and c at a certain point, then the
> version of the collection corresponding to this would have binding
> names b and c.
>=20
> Given a version of a VCR, a system can find that VCR. If our VCR is
> collection /a and if we have binding names b and c in the collection
> version, we can reconstruct /a/b and /a/c. Now we have enough to
> create a new collection with members b and c.
>=20
> I don't find that very strange. What is the difference between copying
> a collection version to another collection, leading to a new version
> controlled collection in the latter, and copying a version controlled
> collection with a label header. Precondition=20
must-select-version-in-history
> in section 8.7 results in some collection version to be used for the
> copy. I could also have specified that collection version directly in
> the request URI.
=20
> Geoffrey M Clemm wrote:
> > It sounds like you are suggesting that the result of the copy depend=20
on
> > what is in the target of the copy?  That would be very strange "copy"
> > behavior (i.e. the result of the copy should only depend on the source
> > of the copy).  Collection versions are for use by "merge" and=20
"update".
=20
> > Werner Donn=E9 <[email protected]> wrote on 08/22/2006 10:59:59 AM:
> >> A collection version has the names of its version controlled bindings
> >> and their version history. It is then possible to find the checked-in
> >> version of the members, which is what is used also when a collection
> >> is copied.

> >> Geoffrey M Clemm wrote:
> >> > A collection version does not have enough information in it to=20
produce a
> >> > sensible copy, since it only records the version history of its=20
members,
> >> > not the versions.  So a collection version is useful for updating a
> >> > configuration, but is not useful for creating a new configuration
> >> > (that's what baselines are for).

> >> > Werner wrote on 08/22/2006 06:34:16 AM:
> >> >> Why should the request fail if the source is a collection version?
> >> >> It seems to me that any version is as good as the checked-in=20
version
> >> >> to copy from.

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


<br><tt><font size=3D2>COPY has to obey the semantics defined for it by RFC=
-2518
(so that an RFC-2518 client can interoperate with an RFC-3253 server),
or must fail.</font></tt>
<br><tt><font size=3D2>Since a collection version is a resource with no mem=
bers,
the result of a successful COPY of a collection version would have to be
the creation of a destination resource with no children. &nbsp;Since this
is unlikely to be the behavior that a versioning client would want, the
COPY request is defined to fail.</font></tt>
<br>
<br><tt><font size=3D2>Cheers,</font></tt>
<br><tt><font size=3D2>Geoff</font></tt>
<br>
<br>
<br><tt><font size=3D2>Werner wrote on 08/22/2006 04:24:25 PM:<br>
&gt; I thought that a version of a collection represented the state of<br>
&gt; that collection at a certain point. So the version-controlled-binding-=
set,<br>
&gt; which is a collection version property, contains the binding names<br>
&gt; that correspond to the members of the collection at that version.<br>
&gt; If collection /a has members b and c at a certain point, then the<br>
&gt; version of the collection corresponding to this would have binding<br>
&gt; names b and c.<br>
&gt; <br>
&gt; Given a version of a VCR, a system can find that VCR. If our VCR is<br>
&gt; collection /a and if we have binding names b and c in the collection<b=
r>
&gt; version, we can reconstruct /a/b and /a/c. Now we have enough to<br>
&gt; create a new collection with members b and c.<br>
&gt; <br>
&gt; I don't find that very strange. What is the difference between copying=
<br>
&gt; a collection version to another collection, leading to a new version<b=
r>
&gt; controlled collection in the latter, and copying a version controlled<=
br>
&gt; collection with a label header. Precondition must-select-version-in-hi=
story<br>
&gt; in section 8.7 results in some collection version to be used for the<b=
r>
&gt; copy. I could also have specified that collection version directly
in<br>
&gt; the request URI.<br>
 <br>
&gt; Geoffrey M Clemm wrote:<br>
&gt; &gt; It sounds like you are suggesting that the result of the copy
depend on<br>
&gt; &gt; what is in the target of the copy? &nbsp;That would be very stran=
ge
&quot;copy&quot;<br>
&gt; &gt; behavior (i.e. the result of the copy should only depend on the
source<br>
&gt; &gt; of the copy). &nbsp;Collection versions are for use by &quot;merg=
e&quot;
and &quot;update&quot;.<br>
 <br>
&gt; &gt; Werner Donn=E9 &lt;[email protected]&gt; wrote on 08/22/2006 10:=
59:59
AM:<br>
&gt; &gt;&gt; A collection version has the names of its version controlled
bindings<br>
&gt; &gt;&gt; and their version history. It is then possible to find the
checked-in<br>
&gt; &gt;&gt; version of the members, which is what is used also when a
collection<br>
&gt; &gt;&gt; is copied.<br>
<br>
&gt; &gt;&gt; Geoffrey M Clemm wrote:<br>
&gt; &gt;&gt; &gt; A collection version does not have enough information
in it to produce a<br>
&gt; &gt;&gt; &gt; sensible copy, since it only records the version history
of its members,<br>
&gt; &gt;&gt; &gt; not the versions. &nbsp;So a collection version is useful
for updating a<br>
&gt; &gt;&gt; &gt; configuration, but is not useful for creating a new
configuration<br>
&gt; &gt;&gt; &gt; (that's what baselines are for).<br>
<br>
&gt; &gt;&gt; &gt; Werner wrote on 08/22/2006 06:34:16 AM:<br>
&gt; &gt;&gt; &gt;&gt; Why should the request fail if the source is a colle=
ction
version?<br>
&gt; &gt;&gt; &gt;&gt; It seems to me that any version is as good as the
checked-in version<br>
&gt; &gt;&gt; &gt;&gt; to copy from.<br>
</font></tt>
--=_alternative 00093EF3852571D3_=--