Next message: jamsden@us.ibm.com: "Re: Target-Selector"
Date: Tue, 28 Dec 1999 00:28:40 -0500
Message-Id: <9912280528.AA15302@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Target-Selector
I agree with Jim. The likelihood of wanting to checkout into
one workspace the revision currently being selected by another
workspace is too small to warrant the introduction of a new header
solely for this purpose. In particular, requiring that the client
use the two requests Tim describes seems very appropriate and
straightforward in case a client finds a need to perform this
action.
Cheers,
Geoff
From: jamsden@us.ibm.com
Why would you want the workspace to contain the checked out working
resource, and the workspace to select the revision to checkout (possibly
with an override-selector) to be different? You wouldn't see the working
resource unless you used the other workspace.
Tim_Ellison@oti.com (Tim Ellison OTT)@w3.org on 12/27/99 08:44:24 PM
Although there doesn't appear to be much interest in this topic (maybe
the time of year), I'll let democracy take its natural course and
conceed spliting the target-selector into workspace: and
override-revision-selector: (or whatever) ... but what about also
allowing a header to specify the workspace in which to checkout a
working resource? The alternative is PROPFIND on the revision
property using a revision selector, and then CHECKOUT on the stable
URL using the workspace selector--yuk!