RE: Why does MERGE automatically checkin resources related to act ivities?

   From: Greg Stein [mailto:gstein@lyra.org]

   > In particular, I noticed in the subversion "mapping to WebDAV" design

   Careful with that doc :-)  it could stand some updating...

Yeah, I figure there's nothing like a bunch of questions to motivate
updating the doc (:-).

   > notes, that you were moving towards using something other than "COPY"
   > to marshal the creation of a "cheap copy".  I believe that
   > BASELINE-CONTROL is the appropriate way to marshal this.  The
   > DAV:baseline-collection property of a baseline exposes that "cheap
   > copy" in an interoperable way.

   Actually, I was planning to do a COPY from somewhere in a BC as the
   marshalling. For example:

       COPY /repos/svn/$svn/bc/567/trunk HTTP/1.0
       Destination: /repos/svn/$svn/wrk/uuid/branches/gstein-work

   This contains the revision/path to copy, and the destination in a working
   collection to copy it to.

The main problem with that marshalling is how can you tell the
difference between:

- someone who wants to create a bunch of new resources, i.e. create a
  set of new VHRs whose initial versions happen to be initialized by
  the content of an existing tree of VCRs.

- someone that wants to create new versions for a set of existing VHRs

In particular, DeltaV defines the semantics of the COPY into a
working directory to be the former, i.e. create a set of new VHR's
when the working collection is checked in.

In order to do the latter, the client would have to CHECKOUT each
resource that they want to modify (both collection and non-collection),
update the resulting working resources, and then check the result
back in (e.g. by MERGE with the DAV:activity-checkin flag set).

Note: My comment above about using BASELINE-CONTROL was assuming you
wanted to create a new set of VCR's for the existing set of VHR's,
but it looks like you aren't planning on supporting that functionality.

   >    > a branch is just a CHECKIN that is not followed by a MERGE).
   >    > This would have CHECKIN of an activity create a new
   >    > subversion revision (aka a DeltaV baseline), but this revision
   >    > wouldn't become the "current" one until you did the MERGE.
   > 
   >    Not supported.
   > 
   > Isn't this just what a "cheap copy" is (i.e. a new revision that does
   > not replace the current one)?

   The copy occurs within a set of working resources. To get a revision, you
   must check in those resources. That revision is then "current".

OK, I misunderstood.  I thought by "cheap copy", you meant creating a
new tree of VCRs that share the VHRs of an existing tree of VCRs.
Instead, you meant creating a tree of (non-version-controlled) resources
within a working collection.

   [ we merge trees when you checkin an activity, and the changes get merged
     with the current revision ]

   We can't do a CHECKIN/MERGE because the checkin operation automatically
   merges. Thus, we could not support a client that looks at those
operations
   as a two step process. Our operation is a single "checkin and merge", and
   the current MERGE semantics models that.

So you are not going to support "revision branching" (i.e. where the
revision history itself branches)?  That does sound vaguely familiar,
so probably you did tell me that a while ago.

   The basic issue here is that the model used by Subversion (and I suspect
a
   goodly number of other systems) does not provide for checking in a new
   "head" revision and hiding it until somebody cares to make it visible.

I thought it was a fairly central CVS feature to create a new "branch"
of the repository, to do a whole series of checkins on a branch, and
then only merge that repository branch on demand (although I agree
that it doesn't to the merge part very well)?  That's what separating
CHECKIN and MERGE is all about.

Cheers,
Geoff

Received on Wednesday, 3 October 2001 09:33:50 UTC