Re: Versioning for dummies

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Thu, 14 Oct 1999 23:28:57 -0400


Date: Thu, 14 Oct 1999 23:28:57 -0400
Message-Id: <9910150328.AA19619@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <8525680B.000EF6E3.00@D51MTA03.pok.ibm.com> (ccjason@us.ibm.com)
Subject: Re: Versioning for dummies


   From: ccjason@us.ibm.com

   I'm not sure if these are suitable for the versioning mailing list.
   They seem pretty simple and fundamental, but they don't seem to be
   clearly answered to me in the versioning doc....

All good questions ... I'll respond to them in the mailing list and
see if we can make the answers clearer in the specification.

   If one checks out resource in a workspace, is one given a new URL to
   use for the CHECKIN?  Or does one just use the URL that one used for
   CHECKOUT?

The latter (i.e. the same URL used for CHECKOUT).  The Target-Selector
header specifies the workspace that contains the working resource that
you want to CHECKIN.

   If one uses the URI that was used for CHECKOUT, then isn't it possible
   for the parent collection to go away in the workspace?

Yes.  But the dav:working-resources property of the workspace gives
you a way to always find all the working resources that you have
checked out into that workspace.

   Is is it possible to issolate changes to a workspace to only changes
   that that were created through the workspace?  Perhaps... make the
   selection rule start with a configuration and then grab the latest of
   an activity.

Yes.

   Then assign a really unique activity name to the
   workspace.

The current spec only allows one workspace to have a given activity
"current" (i.e. being actively updated) at any time.  Some have argued
against that restriction, but I continue to push for it, since it
gives you this "protected world" that you would like.  You can also
do it with ACL's on the activity, but we don't have an ACL spec yet.

   As long as noone changes the activity of the workspace (or
   the rsr), then only changes made within the workspace are visible in
   the workspace, right?

Correct.

   Is there something in the server that insures that only one revision
   of a given resource will contain a given label?

Yes.  That is a required by the protocol.  One of the way it is
enforced is that there is a dav:revision-labels property of a history
resource that is a collection whose members are all the labeled revisions
of that history resource, named by their labels.  Since a collection
can only have one member with a given name, this ensures that only one
revision in the history can have a given label.

   I think you answered this earlier... but the spec talks about a
   workspace having an active activity.  A client can specify an activity
   on a method by method basis, right?

I think we say "current activity", rather than "active activity".
What did you have in mind by "specify an activity on a method by
method basis"?

   Can a workspace have more than one active activity?
   Can a revision be in several activities?

Just one.
These are actually two ways of asking the same question (since the current
activity determines what activity is associated with a working resource,
and therefore what activity will contain the resulting revision when it is
checked in).  The reasons for this restriction is that the purpose
of an activity is to track a logical change, and annotating a single
version with two activities makes it infeasible to "deliver" just one
of those changes to another workspace (i.e. by adding it to the RSR
of that other workspace).

If a single new revision captures changes from two activities, you must
model this as a "do both activities" activity, and have that "do both"
activity set to be your current activity.

Cheers,
Geoff