- From: <Tim_Ellison@uk.ibm.com>
- Date: Fri, 15 Jun 2001 11:13:56 +0100
- To: ietf-dav-versioning@w3.org
"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 on CHECKOUT/CHECKIN. > 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. Tim
Received on Friday, 15 June 2001 07:12:51 UTC