- From: Greg Stein <gstein@lyra.org>
- Date: Mon, 20 Nov 2000 19:16:31 -0800
- To: ietf-dav-versioning@w3.org
On Sun, Nov 19, 2000 at 11:40:38PM -0500, Clemm, Geoff wrote: > > From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com] > > > One way to think about this is that I'm suggesting that checking > > out a collection version should create a workspace (i.e. a tree > > of version selectors), or in other words, that a working collection > > is a workspace. > > Something I blithely glossed over with this proposal was the fact > that a version selector needs a target, and checking out a collection > version gives you the target for a version selector for that collection, > but does *not* give you targets for version selectors for members of > that collection. This would have to be done by the client, with > either a SET-TARGET (e.g. with a Depth header and a label) > or a MERGE (e.g. with a baseline). So the sequence would be: > > - create a new workspace by checking out a collection version > - set the targets of the version selectors in that workspace > with either a SET-TARGET or MERGE request > - do whatever CHECKOUT's, PUT's, DELETE's, CHECKIN's etc. you > want to version selectors in that workspace. > - DELETE the workspace when you are done (or leave it around if > you think you might be doing more work in that collection later. > > This does require two extra requests (the SET-TARGET or MERGE to > get started and the DELETE when you are done), but that does not > seem like an unreasonable amount of overhead. The above model doesn't correspond very nicely with the Subversion (SVN) operational model. Specifically, a number of version resources will be checked out, and then modified. Those versions are not (necessarily) associated with a particular target or a baseline. This means that we cannot issue a simple SET-TARGET or MERGE or anything to prepare the working collection (or workspace, if you will). Instead, the model will be: CHECKOUT /repo/$svn/ver/5/some/collection (modify the thing) CHECKOUT /repo/$svn/ver/7/some/collection/some-file (modify the thing) [ the URLs above are not representative of SVN's actual URLs, but changed to make their intent clear ] Thus, I would be working with two unrelated working resources, rather than in children of the working collection. At another point, I had stated that I didn't want to create a "tree" underneath the working collection, and how I was thinking of accomplishing that. Pretty simple: return 404 for resources under the working collection. Only a DELETE would be allowed for immediate members of a working collection. If you do a PUT or a MKCOL to a member of a working collection, then a new working resource will be created, and that URL will be returned in the 201 (Created) response's Location: header. This allows me to avoid nesting the working resources by effectively redirecting to the created working resource. I'm not sure how a PROPFIND on a working collection would operate, if it had a non-zero depth. I might refuse them to avoid the implication that other resources exist under the working collection. Cheers, -g -- Greg Stein, http://www.lyra.org/
Received on Monday, 20 November 2000 22:15:54 UTC