operational model (was: Re: Working collections)

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