Next message: Geoffrey M. Clemm: "Re: Branching, repositories, and activities"
From: jamsden@us.ibm.com
To: ietf-dav-versioning@w3.org
Message-ID: <85256911.004888A8.00@d54mta02.raleigh.ibm.com>
Date: Mon, 3 Jul 2000 09:12:08 -0400
Subject: Re: Branching, repositories, and activities
But any WebDAV versioning server that uses RCS as its underlying repository
will have to do lots of things in the server implementation to do the
mapping. For example, properties, bindings, and locking will all have to be
implemented in the WebDAV server. This is typical of any implementation of
WebDAV on a repository manager. The mapping of WebDAV semantics onto a
given repository manager may be thick or thin depending on how well the
semantics match. For RCS, a WebDAV server implementation might use a
relational database to store WebDAV properties and locks. It could also use
the database to store versioning meta-data and resources. This is similar
to how mod_dav and DAV4J map WebDAV onto the file system.
So I don't think that just because some repository manager doesn't directly
map to WebDAV versioning semantics implies that we need to complicate the
protocol with special cases supporting that particular repository's model.
Instead we should concentrate on a simple versioning model that supports
the desired scenarios, and make sure it is reasonably possible to map the
model on many existing repository managers. This doesn't mean the mapping
has to be direct though.
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