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.

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

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

So, are you arguing that for an operation to belong in core, a user must
perform it every time they do a CHECKIN?  You want server-generated
identifiers, since it would be unreasonable to expect a user to individually
name each revision, and you also want labels, since it is unreasonable to
expect a user to never want to name any revision.

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

I never argued that LABEL *couldn't* be made optional, just that it
*shouldn't*.  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.

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

- Jim

Received on Thursday, 5 October 2000 18:10:50 UTC