Re: Baselines vs. labels

jamsden@us.ibm.com
Wed, 8 Dec 1999 14:40:42 -0500 

From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256841.006C1B39.00@d54mta03.raleigh.ibm.com>
Date: Wed, 8 Dec 1999 14:40:42 -0500
Subject: Re: Baselines vs. labels



Geoff, I leave this one in your capable hands. As you know, I've never
quite understood the use case for baselines either. I always though a
baseline is just a configuration with one member, a revision of a versioned
collection. Having this associated with the collection in some way, or
constraining it to only contain one member and never be changed just
doesn't seem that important to me, but I'm willing to be conviced with a
compelling use case. Do we have one in the goals document? As far as
performance and optimization is concerned, a server is free to examine the
contents of a configuration when it encounters it in a workspace revision
selection rule, and based on its contents, perform any optimizations it
wants. So if the configuration contained only one member, a revision of a
versioned collection, then the server should be able to do the same
optimizations it would have done on a baseline of the same collection.





"Eric Sedlar" <esedlar@us.oracle.com> on 12/08/99 12:55:49 PM

To:   Tim Ellison OTT <Tim_Ellison@oti.com>
cc:   Jim Amsden/Raleigh/IBM@IBMUS, ietf-dav-versioning
      <ietf-dav-versioning@w3.org>

Subject:  Re: Baselines vs. labels


1) To justify having a "baseline" concept in the spec, I think we need to
have
    * a real customer scenario where the absolute guarantee a baseline will
never be changed is necessary, and
    * show that this is a significant enough case to warrant the complexity
2) Even if you can come up with 1), I would argue that the performance
benefits
of a baseline should be available to whatever mechanism is used to
represent a
release (currently a configuration) since I think that is going to be far
more
commonly used, hence why something like the "baseline configuration"
concept
I'm proposing might be a good idea.
3) I don't see anything in the spec preventing any WebDAV resource
(baselines,
configurations, etc.) from being renamed by a user.  If you did, you would
have
to reserve the entire namespace above the location of the baseline or
whatever,
and make it appear as a read-only filesystem.

--Eric

Tim Ellison OTT wrote:

> <eric>
> >I don't see much utility for baselines if you can never
> >change the revision of a particular file in a baseline.
> </eric>
>
> It gives reproducibility/versioning at a macro level.
>
> <eric>
> <snip ... "performance benefits" ... "baseline configuration" ... >
> >If you want to prevent baseline configurations from being
> >changed, use access control.
> </eric>
>
> That doesn't give you version control, which is the objective.
>
> <eric>
> >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?
> </eric>
>
> My understanding was that administrators could not rename baselines (any
> more than they can rename revisions).
>
> <eric/><snip ... example >