Next message: Greg Stein: "workspace stuff (was: Re: move/copy/delete/etc in a change set)"
Date: Thu, 10 Aug 2000 16:59:39 -0400 (EDT)
Message-Id: <200008102059.QAA12788@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: move/copy/delete/etc in a change set
From: Greg Stein <gstein@lyra.org>
> Now I personally would prefer to just say that every version selector
> is in a workspace, and that you can only have one checkout of a given
> version selector but that's just me (:-).
Bleck. "just me" says that a separate header to be used as a URL prefix is a
hack :-)
I assume you are referring to the Workspace header? This is primarily
useful for clients that store absolute paths in their
resource bodies and properties. You could have the client strip out
the "workspace" prefix before storing an absolute path, and putting it
back on before using it in a request, but it's a bit easier if it can
just leave the absolute paths alone, and just pass in a Workspace header
on every request.
Or are you saying that you like the Workspace header, but don't like
the fact that a workspace is a collection that exposes the workspace
contents? (And if so, what don't you like about it?)
But I'm not sure how this is related to the question of every version
selector having at most one checkout (:-). It's the "checkout
replaces the version selector with a working resource" functionality
which makes workspaces interesting, not the Workspace header. Note: a
system can support workspaces, but not support the Workspace header.
[ there is also the requirement of the WS URL needing to be distinct from
all non-WS URLs;
If a workspace is not a regular resource (with a URL), how would you
find out anything about it or manipulate it? You don't want a whole
new set of Workspace specific methods, like WORKSPACE-PROPFIND,
WORKSPACE-PROPPATCH, WORKSPACE-DELETE, etc.
I find that a problem since I'd want the WS to mirror the
live URL space;
Why is that a problem? If you always use a Workspace header,
it will look like you've got the live URL space at your disposal.
Note that a workspace does not have to be on the same host as the
versioned resources or as other workspaces, so mounting a workspace
at "/" of some host is totally reasonable.
but I don't want WS anyhow, so this is moot :-) ]
As I recall, subversion does all of its workspaces locally on the
clients rather than as web resources, so you probably don't need a workspace
on the server. But it does make keeping track of working resources
much easier!
btw, what I'm doing is mapping Subversion's (http://subversion.tigris.org/)
operating model onto DeltaV. The design is due Monday :-). After that, I get
to start coding. Theoretically, I should have a DeltaV-based Subversion
completed by November/December. (actually, I'm reasonably confident as I
made up those numbers myself :-)
Excellent!! I took a look at the subversion stuff, and it all looked
reasonable (from my quick scan). Let me know if I can be of any
assistance.
Cheers,
Geoff