- From: Peter Raymond <Peter.Raymond@merant.com>
- Date: Thu, 11 Oct 2001 14:11:22 +0100
- To: "Clemm, Geoff" <gclemm@rational.com>, ietf-dav-versioning@w3.org
- Message-ID: <20CF1CE11441D411919C0008C7C5A13B02AD3C11@stalmail.eu.merant.com>
Hi, [Geoff wrote]: >Although the protocol does not require the baseline to >remember the names of members from other baselines, it certainly >can do so... Thanks Geoff, that makes sense. 1. Why not make this the recommended behaviour (that servers SHOULD capture the names of resources that appear in other configurations, rather than not include those resources in the baseline). 2. Another possibility would be to make this client-driven, eg let the client send a XML element in the body of the BASELINE-CONTROL or CHECKIN of a VCCn request to indicate that it wants names captured for resources that appear in other configurations). It seems like such crucial data (in order to make the baseline a consistent snapshot of the baseline-controlled collection). Any preferences as to which of the above approaches? I could add it to my proposed baseline feature extensions/clarifications? Regards, -- Peter Raymond - MERANT Principal Architect (PVCS) Tel: +44 (0)1727 813362 Fax: +44 (0)1727 869804 mailto:Peter.Raymond@merant.com WWW: http://www.merant.com -----Original Message----- From: Clemm, Geoff [mailto:gclemm@rational.com] Sent: 11 October 2001 13:43 To: ietf-dav-versioning@w3.org Subject: RE: Baselines and Bindings From: Peter Raymond [mailto:Peter.Raymond@merant.com] I understand why the baseline of cmp2 would not contain a version of /ws/cmp2/src/bar.html, but this does seem odd. I can think of a common use case for which this may cause problems: ... /ws/project1/news/adverts.js is just a binding to the VCR at /ws/project1/adverts.js. BASELINE-CONTROL on /ws/project1/news BASELINE-CONTROL on /ws/project1 according to Geoffs e-mail I think this will NOT contain adverts.js, it will only capture the default.htm, because the VCR for adverts.js already has a DAV:version-controlled-configuration property and so cannot be a member of two configurations. Correct. This seems really odd, because now if you use BASELINE-CONTROL to populate a new collection with the contents of the baseline that you took of /ws/project1 it will NOT create a advert.js at the top level and so the web page would be broken! Yes, because baselines of project1 depend on baselines of news, so you only get consistent states if you have baselines of project1 contain a subbaseline of news. Even if the baseline of /ws/project1/news was a subbaseline of the baseline of /ws/project1, the adverts.js would still NOT be created at the top level when the /ws/project1 baseline is used. Why not? Although the protocol does not require the baseline to remember the names of members from other baselines, it certainly can do so, in which case it will know to populate /ws/project1/advert.js with a binding to the same VCR as /ws/project1/news/advert.js. If the server supports VCCls, then if for sure will track this information in the binding-set of the collection version for /ws/project1. I don't have a good answer to how I would propose we fix this, but it certainly seems like a problem. We could always just capture one baseline of /ws/project1 and NOT capture /ws/project1/news as a baseline (eg just have one baseline of the whole thing), but this is forcing the user down this route, they may have wanted to track /ws/project1/news as a component. Am I on track? I think the only thing you missed is that a baseline is allowed (and if it supports VCls, required) to track the names of members from other configurations. Cheers, Geoff
Received on Thursday, 11 October 2001 09:13:19 UTC