- From: Alison Macmillan <alison.macmillan@oracle.com>
- Date: Wed, 10 Oct 2001 19:39:03 +0100
- To: ietf-dav-versioning@w3.org
The protocol seems to allow a workspace to contain multiple bindings (names) for a single version-controlled resource. We're trying to understand how multiple bindings coexist with workspaces and baselines, for our implementation. The multiple bindings are introduced in the MERGE and UPDATE semantic additions of the VERSION-CONTROLLED-COLLECTION feature. The DAV:update-version-controlled-collection-members postcondition includes the following condition on new version-controlled member creation: > If a new version-controlled member is in a workspace that already > has a version-controlled resource for that version history, then > the new version-controlled member MUST be just a binding (i.e. > another name for) that existing version-controlled resource. > And an earlier thread talked about UPDATE of a Version Controlled Configuration: > Is This A Bug? > > - Baseline feature: Is it possible to construct a workspace which > contains multiple VCR's with different DAV:checked-in versions > for a given VHR by doing a MOVE of a VCR from one > baseline-controlled collection to another, and then UPDATING the > VCC's for those BCC's? > > I think the intent of the spec is clear (only one VCC for a given > version history in a given workspace), but I agree that > we are missing a postcondition on the MOVE operation. A > workspace is required to have only one VCR for a given version > history, so any operation that would violate that constraint (which a > MOVE could) should fail. Similarly, we should clarify in the extended > UPDATE semantics, so that it is clear that the UPDATE of a VCC causes > an existing VCR to be bound into a collection, if there already is a > VCR for a given version history in the workspace. > I interpreted the last sentence of the reply to mean that the DAV:set-baseline-controlled-collection-members postcondition added by BASELINE to UPDATE (and MERGE), should include a statement similar to that in DAV:update-version-controlled-collection-members, requiring the creation of a binding to an existing VCR in the workspace. Is this the right interpretation? Is it also right to imply that the DAV:checked-in version of the VCR (assuming that it is checked-in) remains as it was preceding the MERGE / UPDATE, in particular the DAV:checked-in version does _not_ necessarily match the version held in the baseline? Should there be a similar extension to the DAV:select-existing-baseline postcondition? This would cover the case of initializing a collection from an existing baseline, where the collection is a member of a workspace, and both the workspace and baseline contain VCRs for the same version history. Also, how should BASELINE-CONTROL behave on a workspace containing such duplicate bindings? For example, suppose a workspace contains /ws/cmp1/src/foo.html and /ws/cmp2/src/bar.html, and that /ws/cmp2/src/bar.html is a binding (another name for) the resource, /ws/cmp1/src/foo.html. If you first BASELINE-CONTROL /ws/cmp1, and then BASELINE-CONTROL /ws/cmp2, should the second BASELINE-CONTROL operation omit the VCR identified by /ws/cmp2/src/bar.html (because it is already a member of a configuration created by baseline-controlling /ws/cmp1)? If it is omitted, then it seems like the baseline of cmp2 has lost some important information about the structure of component 2 (cmp2). If it is not omitted, then it seems to conflict with the description of configuration membership. Thanks, Alison. -- ------------------------------------------------------------- The statements and opinions expressed here are my own and do not necessarily represent those of Oracle Corporation. -------------------------------------------------------------
Received on Wednesday, 10 October 2001 15:36:39 UTC