Re: Baselines vs. labels

jamsden@us.ibm.com
Mon, 6 Dec 1999 19:54:27 -0500 

From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256840.00053FC7.00@d54mta03.raleigh.ibm.com>
Date: Mon, 6 Dec 1999 19:54:27 -0500
Subject: Re: Baselines vs. labels








"Eric Sedlar" <esedlar@us.oracle.com> on 12/06/99 01:59:20 PM

To:   Jim Amsden/Raleigh/IBM@IBMUS, ietf-dav-versioning@w3.org
cc:

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.
<jra>
I meant conceptually cheaper. That is, easier for people to understand an
use, but at a cost with respect to consistent recreation of the
configuration.
</jra>

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.
<jra>
I would probably use a configuration rather than a baseline for this. Then
you can checkout the configuration (assuming its versioned), add the new
member, and checkin the configuration. Now anyone who uses that version of
the configuration will pick up the change, and there is no chance that the
same version of the configuration would pick up something else
unexpectedly.
</jra>

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.
<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>


--Eric