Re: Making "LABEL" optional

I agree that LABEL functionality is very important, and should be
standardized in the protocol, but I don't see that Jim's arguments
identify the significant interoperability problems that will result 
if LABEL is optional functionality.

The "auto-generated filename" argument really doesn't apply here.
The version creation method (CHECKIN) always creates a server-named
object.  The addition of a label to that object is an optional
additional act that can be performed by a client.

The "spellcheck" analogy is much closer, but using this analogy,
although you'd want to have a standard protocol for accessing
spellcheck functionality from a word processor client, greying
out the spellcheck menu item for word processing servers that
don't support it seems like a reasonable thing to do.  Analagously,
greying out the labeling functionality seems like a reasonable
thing to do when a versioning client encounters a versioning server
without label support (just as our client will grey out activity
and baseline functionality when it encounters a server that does
not support activities or baselines).

Cheers,
Geoff

   From: "Jim Whitehead" <ejw@cse.ucsc.edu>
   Date: Thu, 5 Oct 2000 11:03:01 -0700


   > Lisa has asked that we make LABEL functionality optional
   > (i.e. move it into advanced).
   >
   > I personally have no problem with that, since labeling
   > is pretty much orthogonal to CHECKOUT/CHECKIN.
   >
   > Does anyone object? (and if so, please give some reasonably
   > specific rationale).

   I object.

   A label is a mechanism for giving a specific revision a human readable name,
   as opposed to the server (machine) generated version identifier.  While it
   is true that you can support linear versioning without the use of labels, it
   is similarly true that you *could* have a filesystem automatically generate
   an identifier for each file as it is created.  My point? The ability to
   assign a human-meaningful name to a specific revision allows people to more
   easily remember ones that are significant.  Instead of remembering that
   version 1.6 was the one sent out to customers, a label of "Release_A" can be
   used instead. Thus the label feature addresses a basic cognitive recall
   problem inherent in the use of machine generated identifiers for revisions.
   Since the machine generated identifiers are part of core versioning, the
   remedy for them should also be part of core.

   The vast majority of commercial and research versioning systems provide some
   mechanism for assigning a human readable name to a revision, typically in
   the form of a label.  I will take the liberty of assuming that they are not
   blindly coding a feature everyone else has, and have provided it because it
   offers a function their user base has found to be useful.  Doesn't it seems
   that such a commonly occurring versioning feature should also be part of our
   core versioning?

   Finally, I am sure that there exist user communities that are confused by
   the very notion of versioning, who will never use the label feature.
   Similarly, I am sure there are communities of novice word processing users
   that are confused by the very notion of word processing, and never use the
   spell checking feature.  Does that argue for removal of spell checking from
   "core" word processing? I think not.

   - Jim

Received on Thursday, 5 October 2000 15:08:33 UTC