W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2002


From: <gclemm@rational.com>
Date: Wed, 30 Jan 2002 22:32:26 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B105A32305@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org
   From: Kirmse, Daniel [mailto:daniel.kirmse@sap.com]

      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).

That is correct.

   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?

MERGE V-A2 to VCR b without the DAV:no-checkout.
Then copy the content of V-A2 to VCR b, and CHECKIN VCR b.

   By the way: Is the version-history report kind of context dependend?

No, it gives you all versions from the version history of the VCR.

   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.

The version-history report is not a "line of descent" report.  To get
the line of descent, trace back through the DAV:predecessor-set of the
version you are interested in.

Received on Wednesday, 30 January 2002 22:33:32 UTC

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