Re: Making "LABEL" optional

   From: "Jim Whitehead" <ejw@cse.ucsc.edu>

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

   Creation or removal of interoperability problems is a poor criteria for
   determining what belongs in core.  Using this as the criteria, I could argue
   that CHECKOUT should be optional, since it is impossible to identify any
   significant interoperability problems that would result from it being put
   into advanced versioning.

A core client that tries to do a CHECKIN without a CHECKOUT
will fail against an advanced server that requires a CHECKOUT
to precede a CHECKIN.

In contrast, a core client that does not set any labels works
just fine against advanced servers.

   Such a move would raise *oper*ability problems,
   but that is my point. CHECKOUT's inclusion in core versioning depends on its
   utility for basic versioning use.  

I disagree.  CHECKOUT's inclusion in core reflects the fact that the
versioning model requires CHECKOUT's to precede CHECKIN's.  The versioning
model does not require any version to be labeled.

   Similarly, my previous argument was that
   labels provide such a valuable facility, useful across such a wide range of
   users and use cases, that it belongs in core.

This is even more true for a "history resource", but we did not make
that part of core because it was not essential for effective versioning
behavior.

   I illustrated this by
   identifying how labels address the naming problems that accompany the use of
   machine-generated version identifiers.  Since these problems would be part
   of core, it seems to me their remedy should also be part of core.

Labels are not needed to address the naming problem.  I consider the
list that Lisa provided of versioning servers that don't provide
labels as an existence proof of this.  In particular, we already have
a large number of standardized properties that a client can use to
help the user to name and select the version they want.  For example,
in core we provide DAV:creator-displayname and DAV:comment, and 2518
provides DAV:displayname.  In addition, there are a variety of server
generated strings that supplement this user defined information, such
as DAV:version-name, DAV:checkin-date, DAV:getmodificationdate, etc.

A client can just ask for a DAV:version-tree report with the relevant
fields, and the user can use that information to select the version of
interest.

Labels with their "can only identify one version" property are
certainly useful, but by no means essential.

   Any of the methods we're proposing *could* be optional, and a
   client *could* adapt to whatever features the server provides.  The net
   result of this would not be increased simplicity on the client side, though.

I assume that all clients will give their user the ability to browse
(and set) properties like DAV:displayname and DAV:comment on the
versions.  Whether this is supplemented by the ability to put labels
on those versions seems like a reasonable thing to make optional,
with no significant increase in complexity of the client (just grey out
the "label" menu item).

   Labels are such a widely provided feature across version control systems
   that the burden of proof really lies on those who want to move this
   functionality out of core.

I believe that Lisa has now done this.

   I really need to be convinced that the absence
   of labels won't: (a) violate the expectations of versioning-aware users of
   DeltaV applications (I personally would think the absence of labels to be
   extremely odd in a modern versioning system), and (b) lead to increased
   cognitive difficulties due to the absence of revision naming capabilities.

I consider that most of the systems that Lisa identified to be modern
versioning systems ... it's just that they are not software
configuration management systems.  So if our protocol were only
targeted at software configuration management, I'd agree with you, but
I believe it is essential that core be a suitable "core"
(i.e. minimum) for both document management and software configuration
management.

Cheers,
Geoff

Received on Friday, 6 October 2000 18:03:06 UTC