Re: collection version resources

   From: Greg Stein <gstein@lyra.org>

   On Sun, Dec 31, 2000 at 08:40:12PM -0500, Geoffrey M. Clemm wrote:

   > ... so a client would not need to
   > explicitly make a BASELINE-CONTROL request (until we get to subversion
   > "labels", when they would :-).

   Not sure that we need to. I'm thinking that we just label the
   baselines themselves.   Haven't thought much about this one or read
   the spec to flesh it out. Deferring thought for now...

Yes, it would be good to have a "lightweight" label, that just adds a
Deltav label to a baseline, but in an earlier thread, you mentioned a
desire to "expose" that labeled baseline as a tree in the namespace,
which is where the explicit BASELINE-CONTROL would come in.  But
deferring that for later makes sense.

   The response below indicates that I didn't explain the problem well
   enough. Let's get a bit concrete and use some symbols here.

   I have a version history, VH, with versions V1..V5. I have a baseline BL and
   will be committing a change (set) to create BL'. I have one (VCR) resource
   of interest here:
       /A/foo -> V5(VH)
   The change set will be to add another VCR:
       /B/bar -> V2(VH)

   and modify it to create V2.1(VH). Note that I want the two VCRs to
   refer to the same version history so that I can tell that /B/bar is
   related to /A/foo (in that V1 and V2 are shared ancestors).  When I
   check out B to make changes, the working collection is named WC.
   The question is: how to marshal this change set to the server?

OK, I see now where you are coming from.  This is not supported by the
protocol for versioned collections, because it would make a MERGE
request ambiguous (you wouldn't know what the merge-target of a
version would be).  So you can have /A/foo and /B/foo both be
version-controlled resources for the same history, but they have to
select the same version from that history.

   I believe this boils down to the fact that two VCRs in my merge destination
   have the same version history. Thus, the matching of merge versions to merge
   targets is not straight-forward.

   From the other thread about "shared version histories", you would say this
   merge operation is undefined (aka server implementation dependent).

   Eek.

That is correct.  If you want to merge versions into a collection,
then that collection can have at most one version-controlled resource
whose target is a given version history.

   If so, then how do I create two resources with a shared history which exist
   within the same URL namespace? Are we intending to say "not allowed"?

Yes (each resource would need its own history).

   Recap of the issues that have filtered out:

   1) how to marshal "/B/foo -> V2.1(VH)" to the server

      Answer: use BIND to create WC/foo => VH. Check out V2(VH) and modify it.
      At checkin, it will become V2.1(*). The merge step of checkin will do:
	a) create the /B/foo VCR pointing to V2.1
	b) create BL' where /B/foo points to V2.1

Yes.

   2) how to deal with two VCRs (at merge time) that refer to different
      versions from the same version history

   A slightly different way to look at the problem is: if we have two version
   histories H1 and H2, then can we define a way to state that H2 is based on
   H1? That H2's initial version is a specific version from H1?

   If we can do this, then I think we might be okay. Rather than try to share
   version histories (and the resulting problems), I can create a new history
   based on what I'm trying to "copy".

Sure, that would be reasonable.  Perhaps, a "DAV:precursor-set"
property that is automatically set on the destination when you
perform a COPY?  (I figure we might as well make it a set in
case you want to do some "merge" work in that copy before checking
it in).

Then a DAV:predecessor-set would refer to versions in the same version
history, while DAV:precursor-set would refer to versions in other version
histories.  The MERGE and BASELINE operations would be based on versions
connected by the DAV:predecessor-set property, but you could have
version tree displays that showed the cross-version-history links.

   If the related-history thing sounds acceptable, then we can move forward on
   a way to create H2 (as part of the change set represented by an activity)
   and bind it as a member of WC.

With the DAV:precursor-set property, you can use COPY (hey, that's
what you suggested doing in the first place :-).

So, anybody object to the DAV:precursor property that is set whenever
you do a COPY from either a version or a checked in version controlled
resource?

Cheers,
Geoff

Received on Tuesday, 2 January 2001 14:06:59 UTC