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

Re: Comments on Baseline option (in 12.3)

From: Greg Stein <gstein@lyra.org>
Date: Mon, 12 Feb 2001 15:22:14 -0800
To: ietf-dav-versioning@w3.org
Message-ID: <20010212152213.H8123@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.

> 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 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.

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

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.

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?

It is definitely created/updated at checkin time. It could exist as a
protected property at checkout, per the above notes.

> Also, just to make sure I'm not really missing the boat -- the intent is
> 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."

> >    its state is not
> >    guaranteed to be preserved when a version is made of it, since a
> >    version is defined to be (Section 1.4) "A 'version' is a resource
> >    that contains a copy of a particular state (content and dead
> >    properties)".
> >
> > 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.

I'm not sure what the original issue was (missing some quoted text above, it
appears).

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
Received on Monday, 12 February 2001 18:20:12 GMT

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