Re: Revision identifier and revisions label namespaces
Bradley Sergeant (Bradley.Sergeant@merant.com)
Wed, 6 Oct 1999 15:23:28 -0700
Message-ID: <F3B2A0DB2FC1D211A511006097FFDDF5343887@BEAVMAIL>
From: Bradley Sergeant <Bradley.Sergeant@merant.com>
To: "'Geoffrey M. Clemm'" <gclemm@tantalum.atria.com>,
Date: Wed, 6 Oct 1999 15:23:28 -0700
Subject: RE: Revision identifier and revisions label namespaces
WRT moving vs. setting labels...
Is there a way to use a different status when setting a label if the label
is already there vs. moved vs. created, but treat all three as successes?
This avoids the race condition of having to look before you leap and matches
the common usage of many SCM systems. Returning an error would just not be
practical (because of the race condition), when the intent is to move the
label.
--Sarge
-----Original Message-----
From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
Sent: Wednesday, October 06, 1999 1:35 PM
To: ietf-dav-versioning@w3.org
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--