Re: A question about branching, merging

Geoffrey M. Clemm (geoffrey.clemm@rational.com)
Wed, 8 Dec 1999 00:30:09 -0500 

Date: Wed, 8 Dec 1999 00:30:09 -0500
Message-Id: <9912080530.AA01770@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <8525683F.00561006.00@d54mta03.raleigh.ibm.com>
Subject: Re: A question about branching, merging


   bob mcwhirter <bob@werken.com> on 12/03/99 08:53:58 PM

   I'm curious as to how merging is accomplished using DeltaV.

Merging support in DeltaV consists of:
- the DAV:rsr-merge operator in the DAV:revision-selection-rule property
  of a workspace
- the DAV:merge-predecessors property of a working resource and a
  revision
- the conflicts report (DAV:conflicts-report of the REPORT method)

When you want to merge two revision selectors (e.g. two activities
or two baselines), you add them both as operands of a DAV:rsr-merge
operator in the DAV:revision-selection-rule property of your workspace.

You then issue a REPORT request for a DAV:conflicts-report on the
appropriate root collection with your workspace specified in the
Target-Selector header.
This tells you the list of versioned resources that need to be merged,
as well as the base and contributors for each merge (one base, two
or more contributors).

Then (hopefully!) your client has a smart merge tool that uses the
conflicts report to CHECKOUT one of the contributors and then
populate itself with that working resource, the base, and all the
other contributors (otherwise, the user has to do the work of that
merge tool manually).  When a new body and attributes have been
created for the working resource, the client then sets the
"DAV:merge-predecessors" of the working resource to be the list of
other contributors, and requests a CHECKIN on the working resource.

This then captures the merge in the history of the versioned resource.

   From what I can understand in the spec, a CHECKIN of a file
   does not imply any merging.

If you CHECKIN a working-resource with the DAV:merge-predecessors
set, then this does tell the server to remember in the history that
the revision resulting from the CHECKIN represents the merge of
the checked-out revision with the DAV:merge-predecessors.

   Given a resource /index.html (rev1), I can check it out, someone
   else can check it out, into our own workspaces.
   The other person makes edits, and checks in (creating rev2)
   and I then checkin my edits (creating rev3).
   There seem to now be two revision chains:
	rev1 -> rev2
	rev1 -> rev3
   With no corralation between rev2 and rev3, aside from a
   common ancestor.  (Is this correct?)

Yes.

   The spec seems to do some Hand Waving to say that these
   could be merged at a later time, but I can't figure out how.

Let me know if any of the description above is not clear (and yes,
something like this needs to, and will be, added to the spec!).

   Ideally, I'd like to be able to merge rev2 and rev3, creating
   rev4.  Would it be the case that the client performs the
   merges, sets predecessor attributes accordingly, and adds
   rev4 to the server?  While the server reamins blissfully unaware
   of *any* correlation between any of the resources?

The server uses the DAV:merge-predecessors values to
produce a correct conflict report.  For example, if you
ask to merge baseline-11, baseline-14, and activity-3, and
activity-3 was the result of merging baseline-11 and baseline-14,
then the conflicts report will come back saying there are no
conflicts.

   If my first assumption is incorrect, and I have to perfrom
   a merge to create rev3, then I must question how to implement
   branching semantics.
   If required:
	rev1 -> rev2 -> rev3
   then is there really a way to allow checkpointing in
   workspaces (creating revisions) without causing merge headaches?
   I guess my question really boils down to where the semantics
   of your revision control system come into place.

Let me know if the description above leaves anything unclear.

   Or does DeltaV not really attempt to address the issue of
   'conflicts' 'branches' and 'merges', instead, leaving that
   up to implementing in the client tools?

Conflicts are handled by the conflicts report, branches are
modeled by activities, and merges are modeled by the DAV:merge-predecessors
attribute.  The actual merge is handled by the user, hopefully
aided by a smart merge capability provided by the client.

	(btw, anyone else have an active interest in
	investigating build-management and DeltaV/DAV?)

I'm always interested in build-management (just fielded an Odin
question earlier today :-).  In particular, I believe that
"dynamic resources", or as Roy Fielding and I prefer to call them,
"derived resources", are best handled using the techniques of
build-management.

Cheers,
Geoff