Re: Working collections

   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).
(The COPY would just create non-versioned resources).

The SET-TARGET is required by definition to create the appropriate
version selectors, so the client would have to make sure of anything
(assuming the server implemented the protocol correctly).

   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".  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.

   > What happens
   > if you delete a  checked-out child of that working collection?  Does that
   > delete the working resource, or is it still around but invisible when
   > you check it in?

   If a CHECKOUT is done on a "leaf" version (thus creating a working
   resource), and then somebody does a DELETE within that resource's parent's
   working collection, then you have a "merge conflict".

   1) a working resource exists, possibly with changes
   2) the resource has been marked for deletion

You don't "mark a resource for deletion", you just update the membership
of the checked-out collection (remember the mantra: "a deletion is
a modification to the collection containing the object, not to the
object being deleted :-).

   When you commit, the above two conditions are incompatible since the server
   cannot know which takes precedence. So, the commit would fail.
   [ commit meaning a CHECKIN of the related activity, workspace, whatever ]

The removal of a resource from a collection is not incompatible with
the creation of a new version of that resource, so there is no incompatibility
and the commit (CHECKIN) will succeed.

Note that this is not a problem ... the fact that your new version is
not visible in the new version of the collection presents no logical
problems, so I just mention this to avoid any misunderstandings about
what a deletion is and what a merge conflict is.

   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.

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

Cheers,
Geoff

Received on Wednesday, 22 November 2000 16:04:12 UTC