Re: Revision identifier and revisions l

Bradley Sergeant (Bradley.Sergeant@merant.com)
Wed, 6 Oct 1999 12:32:08 -0700 

Message-ID: <F3B2A0DB2FC1D211A511006097FFDDF5343880@BEAVMAIL>
From: Bradley Sergeant <Bradley.Sergeant@merant.com>
To: "'Tim_Ellison@oti.com'" <Tim_Ellison@oti.com>, ietf-dav-versioning@w3.org
Date: Wed, 6 Oct 1999 12:32:08 -0700 
Subject: RE: Revision identifier and revisions l

I have to weigh in here.  I agree that there is a problem if we do not
separate the namespaces of revision IDs and revision Labels.  The spec
intentionally does not specify the value of the revision-id and in general
there CAN be conflicts with labels.  Individual servers could disallow
labels that COULD conflict with their revision-id grammar, but this is
clearly not the way to go (compatibility issues, etc.).

I like the general idea Tim suggested of defining a revision-id: and label:
to separate the namespaces.  Several SCM products work this way, (including
PVCS).  Both options are used frequently, revision-ids when requesting a
specific revision of a single item and label when requesting revisions with
a particular label on a set of items.

--Sarge

		-----Original Message-----
		From:	Tim_Ellison@oti.com [mailto:Tim_Ellison@oti.com]
		Sent:	Wednesday, October 06, 1999 7:11 AM
		To:	ietf-dav-versioning@w3.org
		Subject:	RE: Revision identifier and revisions l


		FWIW my mental model is the same as Dennis'.

		Tim
		 ----------
		>From: infonuovo
		>To: 'Geoffrey M. Clemm'; ietf-dav-versioning
		>Subject: RE: Revision identifier and revisions l
		>Date: Wednesday, October 06, 1999 2:27AM
		>
		>Yes, I agree with the revision identifiers being in
separate namespaces.
		>
		>Thanks for requesting clarification - I replied to the
wrong message!  To 
		be
		>specific, it is my view that:
		>
		>1. A system-defined (i.e., server imposed) revision-id is a
valuable
		>mechanisms for insuring invariants of the versioning model
regardless of
		>what is done with properties and whatnot employed for
application-specific
		>purposes.
		>
		>2. A user-meaningful revision-label is valuable for
carrying
		>application-relevant, human-useful labels that fit
someone's notion of
		>revision identification.
		>
		>It is useful to provide for both, and they could both occur
for a single
		>revision.  In this case, it does not make much sense for
the revision-id 
		and
		>revision-label to share a namespace.
		>
		>With regard to interoperability, (1) has no problems, since
the server has
		>complete say in the matter; (2) requires additional
agreement if a
		>revision-creating client is to honor the scheme expected by
other users of
		>the server.  Rather than leave the revision-label
underspecified, it might
		>be prudent not to specify it, so there is no presumption of

		interoperability
		>or a priori agreement when there is none.
		>
		>[I may be using a different sense of interoperability than
<gmc>.  I 
		haven't
		>considered products being from the same vendor as providing
any assurance 
		of
		>interoperability in live application settings.  I'm willing
to look for a
		>better term for what I have in mind, namely multiple
parties being able to
		>achieve a valid cooperative result without being in
communication.]
		>
		>-- Dennis