Re: Versioning Thoughts (in HTML)
David J. Fiander (davidf@worf.mks.com)
Thu, 06 Jun 1996 08:46:33 -0400
> <p>My personal agenda is that I'm interested in version control as a way to
> relax concurrency to allow write-anytime collaboration. I'm also
> interested in automatic merge tools that will let users manage such
> collaboration, and finding fundamental models of versioning that capture
> the widest range of possible editing behaviours, as a basis for
> implementing generalized systems. I am personally convinced that this is
This sounds good. I hope that we manage to come up with
something that is implementable and satisfies, or at least forms
a basis for, your requirements.
> <p>Accordingly, I believe that version identifiers should be opaque to
> editing systems, and managed by servers. The paper on "VTML" that Fabio
> Vitali and I wrote (referenced in the page for this group) identify a few
> key notions for version management on the web.
I agree. At the bottom, there will be something stored in a
traditional VCS, and they all seem to use different notations for
identifying versions, including arbitrary strings defined by the
user (that is, RCS labels).
> <p>Use of versioning operation should not depend on operations such as
>LOCK and
> UNLOCK. I at least, am taking great pains to avoid the logical or
> practical necessity for such operations by making the free creation of
> variant versions (and their later merging, if desired) as easy as possible.
> I'd like it if we can find a specification for lock and Unlock such that a
> server like the one I am implementing will be able to work with editors
> that expect LOCK and UNLOCK.
I sort of agree and disagree. I feel that we need to define LOCK
and UNLOCK methods, but state that it's up to the server to
decide whether or not they're required before editting, or
PUTing. This allows for a strict locking protocol for those
sites that feel it's necessary while leaving things open for
looser policy.
> <p>It should be a server decision as to what version identifier should be
> assigned to a document revision when it is submitted. This follows from
> the opaqueness of version parameters in URLs. It should be a server
> decision (not mandated by the protocol) whether to accept a new revision.
I agree on both points, but reserve the right to change my mind.
The protocol will certainly not specify that the server MUST
accept a new revision. I can think of at least a dozen reasons,
all policy-based, why a server might refuse a "check-in"
operation.
> It should also be a server decision whether or not the "current version" is
> changed when a version is submitted. Setting the current version should
> also be an available operation, subject to server-specific access and
> configuration policy. I don't object to servers deciding to enforce a
I agree again. Having the default page change whenever somebody
checks something in may or may not be a good thing, but it is,
again, a policy decision.
> <p>I'd like to discuss notions such as VTML as part of the overall
> approach to versioning on the web, thus creating a tripartite front for
> proper support: <tt>Content-type:</tt>, HTTP protocol, and URL format.
> These correspond to the fundamental versioning notions of naming, access
> control, and differencing.
I've looked at the VTML paper, but can't say, right now, any more
than that. I will certainly not accept any attempt to specify
VTML as the storage format. The server may accept VTML as a
format for updating pages, and it may serve VTML to
versioning-aware clients, for display purposes, but how the
server stores things is private.
- David