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

Re: A non-forking server, precussor revisited.

From: <Tim_Ellison@uk.ibm.com>
Date: Fri, 15 Jun 2001 11:13:56 +0100
To: ietf-dav-versioning@w3.org
Message-ID: <80256A6C.003CA530.00@d06mta06.portsmouth.uk.ibm.com>

"John Hall" <johnhall@evergo.net> wrote:

> In my first reading of the specification, I remind myself
> that I probably don't fully understand the spec or how
> people envision that it be implemented.

It is undoubtably a 'deep' read, but it is very useful for people like
yourself to read it without the baggage of previous iterations and give
your impression and opinion.

> I note that there is support for both a forking and a
> non-forking server. A server does not have to implement
> features that allow people to 'fork' version controlled
> resources. I appreciate that. Some situations and clients
> do require that capacity, but many other systems would
> like to do a 'simple' versioning system and don't require
> this.

Just a nit; version-controlled resources have no history, so it is
_versions_ that are forked (or not as the case may be).

> But it seems that the separation isn't clean. If I don't
> support forking, UPDATE, or MERGE, then I see no reason at
> all to keep track of precursor-set.

I'm a bit confused here -- the separation between what is unclean?
The precursor-set is the 'logical predecessors' of the resource either by
copying an existing resource from another version history, or maybe by
manually merging a significant amount of content, or even a significant
concept, from another resource.  It is simply a means of identifying a
historical relationship between two resources that was not directly based

> Geoff said precursor-set was only one href, but I thought
> it was each and every href that had ever been copied on
> top of a versioned resource -- so it is an unlimited set
> of href's.

It is a set of any number of resource URLs that form part of the resource's
logical history.

> So I would strongly prefer that precursor-set be optional.
> An alternative would be that an implementation MAY not track
> precursor-set and MAY set it equal to predecessor-set IF
> it doesn't support MERGE or UPDATE.

I see no point in making it equal to the predecessor set, but I'm also
happy with making it optional.

Received on Friday, 15 June 2001 07:12:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC