- From: Kirmse, Daniel <daniel.kirmse@sap.com>
- Date: Wed, 30 Jan 2002 16:22:15 +0100
- To: "Ietf-Dav-Versioning (E-mail)" <ietf-dav-versioning@w3.org>
Hi, common base: ------------ suppose I have two workspaces A and B. Both of them are under baseline-control (with auto-version). Furthermore I work with working resources and activities and version-controlled collections (to track namespace operations). Further Suppose workspace A contains my current development and workspace B is a consolidation place. Workspace B was created with reference to a baseline of A. I have a VCR a located at workspace A and a VCR b located at workspace B both sharing a version history VH-AB. At time of creation of workspace B from a baseline of workspace A. VCR a and VCR b had checked-in version V1 of VH-AB. Now VCR a was changed and a new version V-A2 appeared. Even so VCR b was changed and a new version V-B2 appeard. Now some time later I want to discard version V-B2 cause it was kind of a blind alley. I use UPDATE to set the checked-in property of VCR b to V-A2. What puzzles me is that there is no predecessor/successor relation in the version-history expressing this UPDATE (at least this my understandig of the UPDATE chapter). The use of MERGE (with DAV:no-checkout) would fail, because V-A2 and V-B2 are sibblings. So the question is: How can this discard be done WITH keeping the information, that the predecessor of V-A2 in the context of VCR b is V-B2? By the way: Is the version-history report kind of context dependend? The question arises due to the update problem. I want to know the version-history of a vcr (respectively the line of descent of the currently checked-in version of that VCR). This Information is needed to revert the UPDATE of VCR b. This must end with V-B2 beeing the checked-in version of VCR b again. Regards, Daniel
Received on Wednesday, 30 January 2002 10:22:58 UTC