Re: Revision identifier and revisions label namespaces

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Wed, 6 Oct 1999 16:35:19 -0400 

Date: Wed, 6 Oct 1999 16:35:19 -0400
Message-Id: <9910062035.AA15072@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <85256802.0046C15D.00@d54mta03.raleigh.ibm.com>
Subject: Re: Revision identifier and revisions label namespaces

   From: jamsden@us.ibm.com

   <deh>
   It makes no sense to have an user-meaningful label and a system-assigned
   unique identifier have anything to do with each other.  One is for the
   internal integrity of the implementation and preservation of the model.  The
   other is for what people or clients agree to use.
   </deh>

   <jra>
   This is not really the case. When a user checks out a revision a
   working resource is created. The workspace rules automatically select
   working resources over any other revision. If a user just checked in
   the resource and never labeled it, then a revision would exist that a
   user had no way to reference. The revision id isn't for internal
   server implementations (although servers are free to use it for
   whatever purposes they desire), its to ensure that all revisions of a
   versioned resource can be distinguished. Think of it as the initial
   label for a revision, one that can't be removed or moved, so you
   always know what you're going to get.
   <jra/>

I agree with Jim's characterization of ids and labels, but I'm not
sure that it conflicts with what Dennis wrote.  The fact that both
id's and labels are used by clients to identify revisions is not
incompatible with the desire to keep the namespaces separate.

   From: jamsden@us.ibm.com

   <gmc/> For any given server, I agree that there could be a simple
   rule that partitions the namespace between identifiers and labels.
   If you have a client trying to run against several servers,
   it could be frustrating to keep colliding with different server
   conventions.

   <jra>
   I don't think the server-generated ids are likely to cause
   many collisions, so I don't think we really have that big a problem
   here.   </jra>

<gmc/> As you indicated above, server-generated ids are the default way
to access arbitrary revisions of a versioned resource.  Since clients
will be using these id's to do selection, I believe servers will be
motivated to make these id's fairly sensible (e.g. small integers).
But the more sensible they are, the more likely they are to collide
with a "sensible" label.  Since we don't want to constrain the id
namespace, I believe that leaves a client with a significant risk
of having a label collide with some server's id convention.

      and collisions are easy to handle.  The
      server will simply refuse to add the label to the revision and the
      user will pick something else.

   <gmc/> You never collide with a label ... you just cause that label
   to be moved to the revision you specified.  But you can collide with
   an identifier, since that is server assigned and cannot be assigned
   (or reassigned) by a client.

   <jra>
   We may want to rethink this. Having a label quietly move from one
   revision to another may not be what we want. Perhaps we should require
   a drop/add paradigm rather than simply label. If not, then I still
   don't think this is much of a problem. There may be other reasons a
   server can't support the label, so the error could still occur.
   </jra>

<gmc/> I believe the case where you want to move a label (as opposed to
create a new one) will be the most common (or at least, very common),
e.g. label something "stable" or "recommended".  In this case, you
cannot detect a "good collision" from a "bad" one.  As for there being
other reasons a server cannot support the label, I believe that should
be a rare occurrence for well designed servers.

      This is the same thing that would
      happen if the revision already had that label for any other
      reason.

   <gmc/> That is a good point, but it is still a very different case
   (one is a collision that fails the label request ... the other moves a
   label that someone was using for something else).  Also note that the
   label problem occurs only if someone has chosen that exact label for a
   revision of that versioned resource.  The identifier collision occurs
   whenever your label has the syntactic shape of an "identifier" for
   that server, even if there is no such identifier on that versioned
   resource, or even on any versioned resource.

   <jra>
   Labeling a revision with the same label twice should return an error.
   </jra>

<gmc/> A common scenario is "label everything in my workspace with a
particular label".  You don't care if it already has that label, so to
force the client to do two round trips (first check to see if it
already has that label, then do the label if it doesn't) would seem
unreasonable.

      Nothing has to be remembered when the label is used in a
      target selector. All in all, I think this is easier for clients, not
      additional burden.  </jra>

   <gmc/> I believe that benefits of avoiding label/identifier collisions,
   combined with the likelihood that a client would need to distinguish
   when it is using a label vs. and identifier anyway, outweighs any benefits
   that might result from unifying the namespaces.

   <jra> I believe the opposite. The likelihood of collisions occuring
   when adding a user label is much smaller than the need to remember and
   distinguish label namespaces when accessing the corresponding
   revisions. One accesses revisions a lot more often than one labels
   them, and the consequences of the collision are minimal.  The user
   just has to pick another label. </jra>

<gmc/> The client program is happy to keep track of 






To: 
Subject: 
--text follows this line--