W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

shared version histories

From: Greg Stein <gstein@lyra.org>
Date: Sun, 31 Dec 2000 05:04:46 -0800
To: ietf-dav-versioning@w3.org
Message-ID: <20001231050445.R28628@lyra.org>
I'm seeing some issues in the draft when a namespace has two VCRs that refer
to versions from the same history.

For example, let's say that I have a version history with:

    V1 -> V2 -> V3 -> V4

In the VCR namespace:

  /coll/foo.c -> V2
  /coll/bar.c -> V4  [copied from foo.c, then extended]

I see two problems arising from this now:

1) a MERGE request is going to have problems because it doesn't know which
   VCR to update when bar.c is moved from V4 to V5. foo.c also refers to the
   same version history, so the MERGE may want to update that to V5, too.

   [ based on my understanding of MERGE which says "update all VCRs which
     refer to the version history of the merge version (V5)". in this case,
     two VCRs do. ]

2) I have a change set style of an activity. The resulting version history
   should look like:

    V1 -> V2 -> V3 -> V4 -> V5

   But the limitations imposed on activities prevents two versions in the
   same line of descent. (but the point is *after* the change set is
   applied, I want two lines of descent)
   [ oh, wait a sec. DAV:unreserved fixes this ]

I have a feeling that problem (1) could be lessened because V5 was created
by checking in a change against V4, so we only update VCRs that refer to V4.
But that isn't actually in the draft, and it might not be desirable (MERGE
isn't always based on checking stuff in; it can also be used for workspace

Okay. (2) is moot. The introduction to activities is very misleading. It
says that versions in an activity must be on a single line of descent.
Twice. Well, that gets completely thrown out later when DAV:unreserved is
described. The introduction should say something about this to prevent
confusion (like I just did above).

I'll look for other issues with shared version histories, but this is my
start. Of course, there is also the problem of getting two references in
there in the first place (in the working collection model; it would appear
that the workspace model can just use VERSION-CONTROL to create the second


Greg Stein, http://www.lyra.org/
Received on Sunday, 31 December 2000 08:00:13 UTC

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