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

Re: "latest" resource

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Sat, 23 Dec 2000 01:19:56 -0500 (EST)
Message-Id: <200012230619.BAA09535@tantalum.atria.com>
To: ietf-dav-versioning@w3.org

   From: Tim_Ellison@uk.ibm.com

       I think the current (10.11) draft gives Greg what he
       want here.  In particular, I'm proposing that we allow
       a MERGE request to checkin every checkout in an activity
       (previously the spec was silent on this case).

   I feel like I'm playing catch-up on MERGE, so bear with me ...

   The proposal is to allow a MERGE /myactivity with Destination:
   /somecollection which will (1) checkin any checked out resources (VCRs or
   working resources), and (2) perform the merge semantics on all the VCRs in
   the activity that have a corresponding VCR (i.e. shared target history) in
   the destination.


   Why do you want to do these in a single operation, why not use CHECKIN and
   MERGE separately?  At least then you'll catch people still working in the
   activity that you are trying to merge.

In Greg's system, his checkin's always create a new baseline (he has
no machinery for capturing work that is not in a baseline).  In addition,
he doesn't want to create the baseline unless it can be placed on
the tip of the "mainline" of the baseline history.  You could try to
introduce something like a "working baseline", but it gets very messy
(I know, I tried :-).  So the auto-checkin on MERGE and the auto-baseline
on CHECKIN appears to be the simplest way to allow him to do what
he wants (and I believe what he wants to do is very reasonable).

   Can the destination be any collection?  Didn't it use to be only a

It can be any collection, but some implementations
will only allow the Destination of a MERGE to be certain
collections (such as, workspace collections, for example :-).

   If it is not a workspace then I presume that all VCRs in the destination
   are merged (transitive closure of all URLs rooted at the destination URL),
   and merges are performed based on shared version history and nothing to do
   with the URL namespace.

That's correct.

   It's going to be a very heavy weight operation on the server, for something
   that I expect people to be using frequently.

If your server can do any kind of "findmerge" (find what needs to be
merged), it's fairly easy to lop off things that aren't in a particular
"Destination collection".  But many/most of us will just constrain what
the Destination can be (in our case, a workspace, in Greg's case, the
collection corresponding to his "repository").

Received on Saturday, 23 December 2000 01:20:44 UTC

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