Re: comparing configurations and baselines

jamsden@us.ibm.com
Mon, 10 May 1999 06:59:47 -0400 

From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <8525676D.003C8806.00@d54mta03.raleigh.ibm.com>
Date: Mon, 10 May 1999 06:59:47 -0400
Subject: Re: comparing configurations and baselines



(I have trimmed the items I didn't have any comments on)




"Geoffrey M. Clemm" <gclemm@tantalum.atria.com> on 05/07/99 05:19:15 PM

To:   Jim Amsden/Raleigh/IBM@IBMUS
cc:

Subject:  Re: comparing configurations and baselines




   From: jamsden@us.ibm.com

   > A configuration is a versionable resource (not necessarily versioned).
   > A baseline is a revision (a deep revision of a baselined-collection).

   It seems strange to talk about a revision of something that isn't a
versionable
   resource. This doesn't feel like consistent semantics. In any case, a
   configuration could be a revision too.

A revision is not a versionable resource.  A baseline is a special kind of
revision (in particular, a deep-revision).  How is this any more strange
than saying that "a revision is not a versionable resource"?
<jra>
I wasn't saying a revision is a versionable resource, but that a baseline is a
revision that was not created by checking in an unversioned resource.
</jra>

If you have a mutable thing that has this "transitively add all members"
property, then you get all sorts of confusing and error prone edge cases.
Let's say you explicitly add a resource.  Then you add a resource that
contains it.  Then you delete the second resource.  Does it take the first
resource out with it, or does the first resource stay around?  On the
other hand, if you just are allowed to take a snapshot, then there is
no question of what to do.
<jra>
This case couldn't happen. If you add a resource, and then attempt to add a
resource that contains it, this would generate an error because a configuration,
like a collection, can only contain a member once.

It looks like most of your concerns are based on implementation considerations
for efficiency. Is there any way we could add restrictions or usage scenarios to
configurations to achieve what you want?
</jra>

Cheers,
Geoff