Re: Baselines vs. labels
Eric Sedlar (esedlar@us.oracle.com)
Tue, 07 Dec 1999 15:33:12 -0800
Message-ID: <384D9937.1DD69829@us.oracle.com>
Date: Tue, 07 Dec 1999 15:33:12 -0800
From: "Eric Sedlar" <esedlar@us.oracle.com>
To: jamsden@us.ibm.com
CC: ietf-dav-versioning@w3.org
Subject: Re: Baselines vs. labels
It seems excessively complex to have three different ways to identify a set of
revisions (for use in revision selection rules). I don't see much utility for
baselines if you can never change the revision of a particular file in a
baseline.
It seems to me that the performance benefits of baselines are based on the fact
that you have a contiguous subtree of revisions, where there is no need to
check the revision selection rules when traversing a link (this often involves
searching through the list of revisions in a versioned resource to find the
latest one or a particular label, etc.). Each collection revision in a
baseline can point directly to the associated revision the next layer down.
What if you introduced a new concept like "baseline configuration". A baseline
configuration would be rooted at a particular versioned collection recursively,
just like a baseline. However, you would be allowed to change the revisions in
a baseline configuration after creating the configuration. Then you can get
rid of baselines & configurations, and simplify the spec. You would get the
performance benefits of baselines plus the flexibility of configurations to
define a particular release of a content group. You could always use labels
for configurations from disparate parts of the URL namespace. If you want to
prevent baseline configurations from being changed, use access control.
Is the reason you consider labels less "reliable" than configurations due to
the assumption that you are protecting them with access control on a bunch of
different resources rather than access control on a single resource?
Also, can an administrator rename baselines? (E.g. I create a baseline from
/amazon/catalogs/music at a particular point in time, and store it in
"/baselines/amazon/catalogs/music/dec6_99.base". Then I modify the revision
selection rules in the workspace I have selected, and create a new baseline
from /amazon/catalogs/music, which includes a different set of revisions, and
call it "/baselines/amazon/catalogs/music/temp.base". Can I delete the first
baseline and rename the second one to have the same name as the first one, thus
changing the selected revisions for anyone who has referenced
"/baselines/amazon/catalogs/music/dec6_9.base" in their revision selection
rules?
--Eric
<jra>
There are three ways to specify a set of revisions:
- a set of revisions sharing the same label
- members of the same configuration
- members of a baseline
Labels are simple, easy to understand, have human meaningful names, are
easy to move around, but aren't immutable and can't be used reliably to
specify a consistent set.
Configurations are a little more complicated and harder to implement, but
have most of the advantages of labels while providing a reliable way to
specify a persistent set of revisions.
Baselines can be thought of (and may be) a configuration whose single
member is a revision of a versioned collection. This simplification can
have performance consequences.
</jra>