RE: CHECKOUT -> MOVE (rename) -> UNCHECKOUT

I agree with Julian.  The URL namespace state is captured in the
collection state and the baseline state, so your server has to
support versioned collections or baselines to capture namespace
state.  For versioned collections, you'd have to CHECKOUT both /foo
and /bar in order to MOVE /foo/a.xml to /bar/b.xml, but you would
*not* have to CHECKOUT /foo/a.xml.  If you then did an UNCHECKOUT
of both /foo and /bar, you would restore the previous state (i.e.
the moved resource is named /foo/a.xml and /bar/b.xml does not
exist).  If instead you did a CHECKIN of /foo and an UNCHECKOUT 
of /bar, you would effectively have deleted the resource.  If instead
you did an UNCHECKOUT of /foo and a CHECKIN of /bar, you would have
two bindings to the same resource, and both /foo/a.xml and /bar/b.xml
would identify the same version-controlled resource.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@greenbytes.de]

> From: Nevermann, Dr., Peter
>
> suppose I have a checked-in VCR at /foo/a.xml and the following scenario:
>
> CHECKOUT /foo/a.xml
> MOVE /foo/a.xml -> /bar/b.xml (i.e. rename)
> UNCHECKOUT /bar/xml

You mean UNCHECKOUT /bar/b.xml?

> Is the resource renamed back to /foo/a.xml by the UNCHECKOUT?

No.

> On one side, RFC 3253 specifies that UNCHECKOUT restores the pre-checkout
> state of the resource (is the URL part of it?). On the other
> side, it should
> be possible to rename a checked-in VCR.

The URL is not part of the state of the resource. In fact, a resource may
have multiple URIs mapped to it.

Received on Saturday, 13 July 2002 11:07:57 UTC