Message-ID: <012901bf41c4$f115b3b0$79442382@us.oracle.com> From: "Eric Sedlar" <esedlar@us.oracle.com> To: <jamsden@us.ibm.com>, <ietf-dav-versioning@w3.org> Date: Wed, 8 Dec 1999 13:41:10 -0800 Subject: Re: Baselines vs. labels The performance optimization for baselines comes from the fact that you don't have to scan the list of revisions for a particular versioned resource at each level, which probably means not evaluating any revision selection rules. If I have thousands of revisions, I will have to do a disk-based index search to evaluate the rule at each level of the hierarchy. This sucks. If I have a baseline, I can store a link hint to with each REVISION of a collection which points to the next REVISION down the baseline, recursively. Since the baseline never changes, you don't have to worry about the cost of maintaining this information. If you allowed a baseline to be modifiable on a onesy-twosy kind of basis (which is the typical use case), the storage implications of updating these link hints are minor. --Eric ----- Original Message ----- From: <jamsden@us.ibm.com> To: <ietf-dav-versioning@w3.org> Sent: Wednesday, December 08, 1999 11:40 AM 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 > > > > > > >