Re: Baselines vs. labels
Eric Sedlar (esedlar@us.oracle.com)
Mon, 6 Dec 1999 10:59:20 -0800
Message-ID: <003c01bf401c$00d9f810$79442382@us.oracle.com>
From: "Eric Sedlar" <esedlar@us.oracle.com>
To: <jamsden@us.ibm.com>, <ietf-dav-versioning@w3.org>
Date: Mon, 6 Dec 1999 10:59:20 -0800
Subject: Re: Baselines vs. labels
Questions and comments...
> Can someone give a bit of rationale for when you use baselines and when
> you use a label applied recursively to all the elements of a
> collection? Is a baseline just a specialized case of a label?
>
> Eric,
> The difference is that labels can move while the members of a baseline or
> versioned configuration don't change. So while labels can be used to
create
> cheap "labeled configurations", they aren't stable and are subject to easy
> change. Clients are welcome to use them this way as long as they follow
> established conventions about promoting, removing, and otherwise moving
> labels.
> </jra>
Why do you expect labels to be cheaper? Cheaper in CPU costs when
evaluating
the revision selection rules, cheaper in storage costs, or what? The only
thing I
can see that makes a baseline more expensive is assigning a spot in the URI
namespace to it, which would be minimal.
When do you recommend using recursive labels vs. a baseline? For typical
configuration management needs, if I want to create release 1.0.1.1 of my
product, it seems like I might want the ability to slip in a new revision of
a file
at the last minute, which would mean moving a label from version to version.
I couldn't do that with a baseline, since I would need a new baseline, which
would have a different URI, so this wouldn't be transparent to people who
were already using release 1.0.1.1 of my product. It might be useful to
include
some scenarios in the spec as to when to use either.
Since version management systems like CVS use tags (i.e. labels) in this
way,
I think some clarifications in the spec in this area would be helpful.
--Eric