Next message: Jim Doubek: "Versioning Phone Conference?"
Date: Mon, 1 May 2000 12:58:11 -0400 (EDT)
Message-Id: <200005011658.MAA11048@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Resource vs. Revision Properties
From: "Tim Ellison/OTT/OTI" <Tim_Ellison@oti.com>
<jimd>
I have 2 concerns:
1) If the revision history is multi-tipped (i.e., there are
unmerged working tips), the revision selection behavior is not
deterministic as described. Which tip is selected?
2) In such a case, the forwardgoing structure still won't be linear, which
seems to be the intent of this property.
OTOH, if a history is non-linear, but the current state is a single
tip, the property works as I believe it's intended - to prevent
future bracnhing. That situation ought to be just fine.
</jimd>
<tim_2 weasel="on"> Depends upon the functionality that is
desirable. My understanding is that it intended to prevent >1
working resource for a given versioned resource, and thereby avoid
the merging problem (i.e., serialize updates). However, this
property pre-dates me, so I'll leave it up to one of the protocol
doc authors to defend it ;-)
As a potential client, DAV:single-checkout is more interesting to
me since it avoids merging problems. As a potential server,
DAV:linear is more interesting, since I can use it to implement DAV
on a non-branching store. <tim_2>
The "single checkout" doesn't actually avoid merging, since if you
checkout a non-latest revision, a client might reasonably want to
merge that with the revisions that were later than the one that you
checked out. So I still vote for JimD's suggestion for a "single tip"
semantics for DAV:linear.
Cheers,
Geoff