W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2001

Re (4): Re[2]: baselines & namespaces

From: <Edgar@EdgarSchwarz.de>
Date: Fri, 28 Dec 2001 08:39:50 -0500
Message-Id: <200112281339.IAA18176@tux.w3.org>
To: ietf-dav-versioning@w3.org
Cc: Edgar@EdgarSchwarz.de
"Clemm, Geoff" <gclemm@rational.com> wrote:
>    > If your server supports baselines and versioned collectios, then
>    > it MUST create /ws/kk/x/y when /repo/bl/22 is merged into /ws/kk.
> 
>    Why should this be required ? /ws/kk/x/y wasn't captured in the
>    baseline, so there is no information how to restore it.
> 
> The baseline /repo/bl/22 contains a collection version for "./x/y",
That's already the point I don't understand.
My reasoning goes like that:
0. It doesn't matter whether the server also has versioned collections because
   baselines and versioned collections are independent features.
1. /repo/bl/22 is a baseline of the configuration rooted at "./x".
2. It was explicitly stated in the original question that "./x/y" is the root of
   another configuration which isn't a subbaseline of "./x".
3. A baseline is a set of versions of version-controlled-resources with the exception
   of resources which belong to another configuration.
=> Baseline /repo/bl/22 doesn't contain a collection version for "./x/y",
So where's my error ?


> This is allowed to provide consistent semantics in the presence of
> versioned collections.  A version of a collection captures a set of
> version-controlled bindings, and an appropriately named binding to a
> VCR must exist when that collection version is restored
> (i.e. specified in the DAV:checked-in property of a version-controlled
> collection).
After thinking about my points above I guess that you probably already disagree
with point 0. Right ?
In this case I think I can stop argueing with you. Because as long as there aren't
versioned collections I think we agree.

Now suppose there are only baselines. In an earlier post you granted that it would
make sense for the server to save the relative position of the subbaseline somehow.
So it knows where to restore it later.
Do we already have a property to do that ? If not I think we should create it.
Or is there another mechanism using existing features ?
At least is should be guaranteed that subbaselines are restored to the same relative
position like when the baseline was created.

Cheers, Edgar
  
-- 
edgar@edgarschwarz.de                    http://www.edgarschwarz.de
*          DOSenfreie Zone.        Running Active Oberon.         *
Make it as simple as possible, but not simpler.     Albert Einstein
Received on Friday, 28 December 2001 08:39:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:43 GMT