Next message: Geoffrey M. Clemm: "Re: workspace stuff (was: Re: move/copy/delete/etc in a change set)"
Date: Thu, 10 Aug 2000 18:42:02 -0700
From: Greg Stein <gstein@lyra.org>
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
Cc: ietf-dav-versioning@w3.org
Message-ID: <20000810184202.K19525@lyra.org>
Subject: workspace stuff (was: Re: move/copy/delete/etc in a change set)
On Thu, Aug 10, 2000 at 04:59:39PM -0400, Geoffrey M. Clemm wrote:
> 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?)
The former. The header means that the /foo/bar.html is not necessarily
unique. The URI is further differentiated by another header (thus leading
into the whole "Vary" thing). For a multiple-use server such as Apache, the
header means that stuff can just "show up" at URLs that weren't
administratively created.
I do agree that a workspace can/should be exposed as a resource. No problem
there.
> But I'm not sure how this is related to the question of every version
> selector having at most one checkout (:-).
It's not :-)
[ for the record, I want multiple checkouts, but only for short periods of
time -- the client will do MKACTIVITY, CHECKOUT, MERGE <activity>; if a
couple clients are hitting the server at the same time, there is a point
between CHECKOUT and MERGE where they could both have it out at the same
time; I want this allowed in case the first client aborts before the final
MERGE step; I don't want the second guy prematurely locked out ]
> 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.
Interesting thought. I was about to ask how that is accomplished, but just
noticed the explosion of tags in section 12.2 to specify what is supported
in detail.
> [ there is also the requirement of the WS URL needing to be distinct from
> all non-WS URLs;
>...
> 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.
Euh. Nope. Section 11.1 is the issue I'm referring to. It states that any
request with a Workspace header must fail if there is a corresponding
internal member.
In other words, I have /project/index.html on my server. I can't just shift
that into a workspace and use it /project/index.html. It must be
differentiated somehow, say /ws/project/index.html. If it must be
differentiated, then why bother with the Workspace header? If I can say
/ws/..., then I can say /ws/gstein/3/... just as easily.
This is the "feature" of workspaces that I disagree with. I'm a late comer
to this, so I'm assuming there is a valid reason for the design. That's why
I said "just me" doesn't like it, and I'm not going to argue against its
inclusion.
> 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.
We're back to the hacky nature of this stuff :-) A whole separate host name
just to deal with the Workspace header? hehe. Really, listen to what you're
saying :-)
> 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!
Yes, yes, and agreed.
The server-side of Subversion (built using Apache/mod_dav as the network
engine) may support non-local development at some point. But certainly the
first version of both sides will require the local (client-side) copies.
> 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.
Thanx!
Cheers,
-g
--
Greg Stein, http://www.lyra.org/