Re: Revision identifier and revisions label namespaces
Bradley Sergeant (Bradley.Sergeant@merant.com)
Wed, 6 Oct 1999 15:37:00 -0700
Message-ID: <F3B2A0DB2FC1D211A511006097FFDDF5343888@BEAVMAIL>
From: Bradley Sergeant <Bradley.Sergeant@merant.com>
To: "'Chris Kaler (Exchange)'" <ckaler@Exchange.Microsoft.com>,
Date: Wed, 6 Oct 1999 15:37:00 -0700
Subject: RE: Revision identifier and revisions label namespaces
Yes, we defined it as a move. I was responding to the mail thread. Read a
little further to the comments between Tim, JimA, and Geoff.
The race condition is if it is not a move. I was pointing out one reason
why it must be (as we have said) a move.
--Sarge
-----Original Message-----
From: Chris Kaler (Exchange)
[mailto:ckaler@Exchange.Microsoft.com]
Sent: Wednesday, October 06, 1999 3:44 PM
To: 'Bradley Sergeant'; 'Geoffrey M. Clemm';
ietf-dav-versioning@w3.org
Subject: RE: Revision identifier and revisions label
namespaces
I don't understand -- haven't we defined the semantics to
be that it moves to the specified revision. In which case,
you can just leap...
It would be interested to know if the label was created
or moved, and both should be success, I just don't
understand
why a client would need to look first
Chris
-----Original Message-----
From: Bradley Sergeant [mailto:Bradley.Sergeant@merant.com]
Sent: Wednesday, October 06, 1999 3:23 PM
To: 'Geoffrey M. Clemm'; ietf-dav-versioning@w3.org
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--