- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Sat, 23 Dec 2000 01:19:56 -0500 (EST)
- To: ietf-dav-versioning@w3.org
From: Tim_Ellison@uk.ibm.com <Geoff> 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). </Geoff> 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. Yes. 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 workspace? 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"). Cheers, Geoff
Received on Saturday, 23 December 2000 01:20:44 UTC