Re: default workspace vs. set-default method vs. default label

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Sun, 14 Mar 1999 22:29:16 -0500 

Date: Sun, 14 Mar 1999 22:29:16 -0500
Message-Id: <9903150329.AA17212@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: damon@ede.com
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <199903142130.QAA15079@roxie.ede.com> (message from Damon Poole
Subject: Re: default workspace vs. set-default method vs. default label

Damon Poole and Jim Amsden both provide compelling (at least to me)
reasons for *not* following my suggestion to limit default version
selection to simple "set-default-revision" functionality.  For example,
a branch or change-based server will probably want to require that
defaults be specified in terms of branches or change-sets, not isolated
revisions (thus ensuring some level of inter-resource consistency).

So it sounds like a more acceptable proposal is to say that default
revision selection is specified by the revision-selection-rule of a
default workspace, and that minimally a server must support a

   <DAV:label> latest </DAV:label>

revision-selection-rule.

If a server only has to support a revision-selection-rule in the
default workspace, and does not have to allow modification of the
default workspace's revision-selection-rule, I believe this ensures
that a server needs to do no more work than that required for a
"set-default-revision" method.

Is this a generally acceptable compromise?

Cheers,
Geoff

   X-Mailer: exmh version 2.0zeta 7/24/97
   Mime-Version: 1.0
   Date: Sun, 14 Mar 1999 16:30:24 -0500
   From: Damon Poole <damon@ede.com>
   Resent-From: ietf-dav-versioning@w3.org
   X-Mailing-List: <ietf-dav-versioning@w3.org> archive/latest/140
   X-Loop: ietf-dav-versioning@w3.org
   Sender: ietf-dav-versioning-request@w3.org
   Resent-Sender: ietf-dav-versioning-request@w3.org
   Precedence: list
   Content-Type: text/plain; charset=us-ascii
   Content-Length: 1892


   Geoff writes:
   > In order to provide interoperability, the level-1 technique for
   > "setting the default revision" of a versioned-resource should work
   > when applied to a versioned-resource being maintained by a level-2
   > server.
   > 
   > If a level-2 server uses a default workspace, with the
   > revision-selection-rule of the default workspace determining default
   > revision selection, then one would have to provide a "set-default"
   > method for level-1, and in general, a "set-default" might fail
   > against an arbitrary revision-selection-rule.

   > So from my perspective, the best choice is to get rid of the notion of
   > a "default workspace", and stick with the notion of a "default label".
   > Then you just set the default label when you want to adjust the
   > default revision of any particular versioned-resource, and you require
   > that CHECKIN automatically move the default label to the new
   > revision, if predecessor of the new revision is the current default
   > revision.

   Please pardon me if I'm way off base here. I think I'm mostly up to date
   but I may have missed something along the way. Anyway, it seems to me
   that replacing the default workspace with a default label would be giving up a 
   lot of flexibility and adding a fair amount of extra work in some situations.

   For instance, I assume you can arbitrarily change the definition of the 
   default workspace to use a different branch or label whereas to get the same 
   effect with labels you would have to relabel everything.

   It may take some effort to make sure that the set-default cannot fail or that
   there is some sort of default-default (!) in case of failure, but it seems
   worth it in light of the potential loss in ease of use.

   On the other hand, it also seems like the default label could be the
   interim solution until such time as the set-default failure case is
   adequately resolved.

   Cheers,

   Damon Poole
   Ede Development