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

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

From: <Edgar@EdgarSchwarz.de>
Date: Fri, 28 Dec 2001 17:07:08 -0500
Message-Id: <200112282207.RAA02564@tux.w3.org>
To: ietf-dav-versioning@w3.org
Cc: Edgar@EdgarSchwarz.de
"Clemm, Geoff" <gclemm@rational.com> wrote:
>    "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",
>    > and this collection version has a version-controlled binding named
>    > "y".
> Note: I meant to say "the baseline /repo/bl/22 contains a collection
> version for ./x".  Sorry about the typo.
Now I think I finally understand what you are getting at.
As a baseline can't catch a collection version without VERSION-CONTROLLED-COLLECTIONS
I also didn't expect that with this feature available.
I'm not sure whether this is really necessary. Something to ponder on the weekend.
But I guess it looks obvious to sombody having experience with e.g. Clearcase
wanted to avoid more complexity.

>    In this case I think I can stop argueing with you. Because as long
>    as there aren't versioned collections I think we agree.
> Yes, if a server does not support version-controlled collections, then
> it can chose to not create a VCR named /ws/kk/x/y.  But note that a
> client must be prepared for /ws/kk/x/y being created, since that is
> what it will see on a server that supports version-controlled
> collections.

>    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.
> I agree that for "immediately nested" sub-components, it makes sense,

> but for non-nested sub-components, it probably does not.
> Suppose you have a baseline for /ws/gmc/xx that has a subbaseline
> named /ws/gmc/yy.  And you have a baseline for /ws/es/zz that has
> a subbaseline named /ws/es/yy.  Then you "merge" the baseline for
> /ws/es/zz into /ws/gmc.  You get a name collision for /ws/gmc/yy.
Then it could be the users job to remove the collision e.g. by moving
the already existing /ws/gmc/yy out of the way. In any case he has
to do some restructuring if this happens. But I guess that's outside
of the spec.

> The main reason we didn't
> specify this as an independent postcondition is that in the
> defined packages, version-controlled collections always appear
> whenever baselines appear, so this postcondition follows from the
> existing postconditions of those two packages.
> I expect that adding the postcondition that nested subbaselines are
> restored in their same relative location will be acceptable to
> everyone, so the best approach here is probably to get this written up
> and posted to the deltav web site, so that deltav implementors are
> aware of it as a likely addition in the next rev of the deltav spec.
Good. Then would it be clear also in case of BASELINES without
VERSION-CONTROLLED-COLLECTIONS. It's just that I still think that I can
do with BASELINES all what I want. So even if it's the obvious solution
I think it's useful to have it written down somewhere.
It's just my fear that these two features will lead to complex
interactions and also confusion if they are both implemented. They are
different solutions for similar problems so I want them to be as standalone
as possible. 

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 17:07:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC