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

Re: Comments on Baseline option (in 12.3)

From: Clemm, Geoff <gclemm@rational.com>
Date: Sat, 24 Feb 2001 00:52:31 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B10221D1F0@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org
   From: Greg Stein <gstein@lyra.org>

   On Mon, Feb 12, 2001 at 11:01:20AM -0800, Jim Whitehead wrote:

   > >    6. Section 10.3.1 & Section 10.11 (DAV:baseline-collection)
   > >    Since this is a protected and computed property,

   > > (actually, I believe it is just a protected, not a computed,
   > > property)

   In Subversion, it is computed and protected.

In the versioning protocol, the term "computed" has a specific meaning
when applied to a property value (section 1.4.3).  Basically, it says
that the property value is defined in terms of a specific computation,
as opposed to being defined in the postconditions of the method that
updates it.  The DAV:baseline-collection is defined in the
postconditions of the method that creates it (i.e. CHECKIN and
BASELINE-CONTROL) and therefore DAV:baseline-collection is marked as
being "protected" but not "computed".

I did notice that the BASELINE-CONTROL method only indirectly defines
the DAV:baseline-collection property of the root baseline of a new
baseline history.  I'll fix this to be more explicit.

   > Hmm, then this is another area that needs to be fleshed out.
   > While a baseline is checked-out, the server automatically
   > maintains the value of the baseline, right?  This would imply
   > that at any time while a baseline is checked out, a client could
   > read the value of the DAV:baseline-collection of the checked-out
   > baseline, and receive an up-to-date, consistent baseline. Is this
   > correct?

A resource type has a given live property iff the protocol says that
it does.  According to the protocol, only a baseline is defined as
having a DAV:baseline-collection.  A working configuration (which is
the result of checking out a baseline) is not defined to have a
DAV:baseline-collection, nor is a version-controlled configuration.

   A checked-out baseline is exactly the same as the baseline referred
   to by its DAV:checked-out property. Specifically, there isn't
   anything that you can do with a working baseline to change its
   contents. Consistency is implicit, so the DAV:baseline-collection
   would continue to be valid.

If it had one, which it doesn't (:-).

   A working baseline is good for storing new (dead) properties on a
   baseline, but not much else.

Actually it is also good for setting the ever popular
DAV:subbaseline-set property (:-).

   The set of versions captured by a baseline are defined by a
   relationship with a version-controlled configuration (VCC). A
   working baseline does not have this relationship, so it cannot
   affect the set of versions. Other "stuff" is needed. For example,
   if you check out a baseline into an activity, then you can find a
   version-controlled configuration at MERGE time by using the
   DAV:version-controlled-configuration property of the merge target.


   [ there is also a way to create a baseline by checking out the VCC and
     checking it back in -- it will snapshot the related
     baseline-controlled-collection. ]


   > If so, then this sounds like a computed property to me.

Yes, by the standard English meaning of the term "computed", but not
by the DeltaV definition (which is all about where to look in the
specification for the definition of the semantics of the property).

   Well... the server always assigns it, and it will typically be constant
   after that point.


   > Or is it that, when checked-out, there is no DAV:baseline-collection
   > property, and then when checked-in, this property is created with the
   > correct value?


   > Also, just to make sure I'm not really missing the boat -- the intent
   > that the client is not responsible for maintaining the value of
   > DAV:baseline-collection property directly (i.e., by PROPPATCHing this
   > property), right?

   Correct. The server says "over <there> is a URL namespace that looks like
   the baseline-controlled-collection at the time the baseline was created."


   > > A version-controlled configuration does not have a
   > > DAV:baseline-collection property, so I don't see that this
   > > issue arises.  It is only a property of a baseline.

   > This implies that the DAV:baseline-collection property does not
   > exist when a baseline is in checked-out state.  Is that correct?

   I think Geoff is mistaken here. Since a VCC is essentially a VCR, then it
   should have all the properties of its DAV:checked-in value, which is a
   baseline. Thus, it should have a DAV:baseline-collection property.

Only the dead properties of a VCR have the same values as the
corresponding properties of its DAV:checked-in version.  There are
many live properties of a version that do not appear on a VCR
(DAV:successor-set, DAV:version-name, DAV:label-name-set, ...).

A VCC is a VCR, so it has all the live properties of a VCR (since it
is a VCR), but it is not a baseline, so it does not have all the
live properties of a baseline.

Received on Saturday, 24 February 2001 00:53:03 UTC

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