Next message: jamsden@us.ibm.com: "Re: Branching, repositories, and activities"
Date: Sun, 2 Jul 2000 23:03:36 -0400 (EDT)
Message-Id: <200007030303.XAA03092@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Branching, repositories, and activities
From: jamsden@us.ibm.com
Why bother with CHECKOUT/new-activity? It adds another switch to an
already complicated method. How would this introduce any new
capability over the second approach? Are you saying a server might
support creating an activity on checkout, but not as a separate
resource? If so, couldn't a WebDAV implementation on such a
repository handle this situation with a simple mapping?
Consider a server that implements a versioned resource as
an RCS file. It doesn't have a repository, and implements a
revision URL as some simple munging of the versioned resource
URL (e.g. "/foo/test.html;1.3.1").
There is no "repository", and it has no way of reliably linking to a
set of revisions (the revision URL's just become invalid when the
versioned resource is moved or deleted). Because of this, it would be
hard (and therefore is unlikely) for such a server to implement an
activity as an independent resource. But it would be trivial for such
a server to support a "CHECKOUT/new-activity" request, since it could
just branch the versioned resource. The new activity would be given a
server defined URL such as "/foo/test.html;1.4" (in RCS, an odd number
of dotted segments is a version id, while an even number of dotted
segments is a branch id).
I agree that a checkout/new-branch adds another option to the
checkout method, so if nobody is interested in the RCS style
per resource branching implementation, we could take it out of
the protocol.
Cheers,
Geoff