W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

Re: Working collections

From: Greg Stein <gstein@lyra.org>
Date: Sat, 2 Dec 2000 23:21:27 -0800
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
Cc: ietf-dav-versioning@w3.org
Message-ID: <20001202232127.H27216@lyra.org>
Okay... I'm responding to this one to knock off a few items and (hopefully)
close up discussion on these lines of thought. I think the "unversioned
resources in a working collection" model might work. But that'll go into a
different thread.

On Wed, Nov 22, 2000 at 04:03:32PM -0500, Geoffrey M. Clemm wrote:
>    From: Greg Stein <gstein@lyra.org>
> 
>    After you create a workspace, then it must get populated with the
>    resources that you want to work with. So wouldn't that be something like:
> 
>        MKWORKSPACE /some/whwere
>        COPY /repos  -> /some/where/repos
> 
>    And then you start working with /some/where/repos ? Ooh, and the client also
>    has to make sure the result of the COPY actually creates version selectors,
>    doesn't it?
> 
> Actually, it would be a SET-TARGET (with a label or a baseline).

We don't have a label or baseline that corresponds to what resides on the
client machine. We would use a SET-TARGET to the appropriate collection
version. If I understand this stuff properly, this would set up the version
selector at /some/where which would implicitly create a tree of version
selectors (via slash-through on /some/where).

> (The COPY would just create non-versioned resources).

They could automatically be placed under version control.

However, that wouldn't work well for my situation since I'd want to "hold
them back" until the person committed the change set. As a result, versions
and version histories shouldn't be created until that point. This, of
course, means that the COPY would create non-versioned resources :-)

[ but this is where we're going in the other thread, and that doesn't need
  workspaces, so I'm not going to explore this further... ]

>....
>    Hmm. I guess you could use VERSION-CONTROL instead of COPY to set up the
>    workspace contents. But... it isn't a simple matter of "just create a
>    workspace".
> 
> A single SET-TARGET call would do it (with a Depth header, for the label
> case), so I think it's reasonable to call it "simple".

SET-TARGET with a version. Yes, that would be simple (for the client).

> The client is going
> to have to tell the server what versions it wants to "checkout", so it
> is just as easy for it to tell the server to do a SET-TARGET for each CHECKOUT
> so that the workspace is targeted appropriately.

Right. Each checkout would be a pair of requests.

>...
>    A tree of version selectors is rather difficult to maintain on the server,
>    compared to a set of working resources. At any point in the tree, you would
>    need to figure out which is checked out, which is not. If something is
>    checked out, then what version? And as you pointed out in another note, what
>    is the target of each version selector? In Subversion, I need to work with
>    specific version resources (much easier than trying to prep a version
>    selector to point at the version that I'm concerned with).
> 
> If you implement a workspace as a label and a set of working
> resources, then you just move the label whenever someone says
> SET-TARGET, and check to see if you have a working resource for that
> version history before returning the labeled version.  You do have the
> cost of setting the labels for each workspace, but you now have all
> the robustness/recoverability benefits of the server knowing the state
> of the client.

The labels are a big cost, and I also don't want to maintain that much
state. It is *incredibly* simpler for Subversion to establish a working
resource for a particular version resource(*), than it is to maintain a set
of mappings of version selectors to specific version resources. (the main
view of the repository are simply version selectors to the "latest" version
resource which means the mapping is quite simple)

(*) each version resource is identified by a dotted sequence of numbers. We
just include that sequence in the working resource URL to identify the
version resource the w-resource corresponds to. Simple :-)

> But I probably can live with adding the notion of a "working collection"
> to the protocol, if you remain unconvinced (:-).

:-) ... yes, I think the working collection is the appropriate path.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
Received on Sunday, 3 December 2000 02:20:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:39 GMT