Re: Merge Example in <version-goals-01221999.htm>

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Sat, 23 Jan 1999 17:27:46 -0500 

Date: Sat, 23 Jan 1999 17:27:46 -0500
Message-Id: <9901232227.AA19135@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: sds@jazzie.com
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <m103v9I-000OW3C@jazzie.com> (sds@jazzie.com)
Subject: Re: Merge Example in <version-goals-01221999.htm>


First a note for the folks interested in simple versioning: this is a
"configuration management" scenario.  Activity and workspaces do not
appear in "document management", since this level of control (and its
associated increase in complexity) is not required.

   From: sds@jazzie.com (Sean Shapira)

   The <version-goals-01221999.htm> draft provides an excellent
   fictitious example of a version control system in use, showing
   how "activities" are used to prepare for later merges.  But the 
   example does not make clear where merged revisions appear in the 
   revision histories of versioned resources.

That is actually intended.  That information would appear in
the "versioning model" and "versioning protocol" documents.
The goals document is just intended to layout the terminology and
the problem/scenario space.

   As it happens, this fictitious usage scenario also provides an 
   excellent opportunity for discussion of some apparent weaknesses 
   in "first checkout is special" revision control systems.

One of the reasons that the concept of an "activity" was
introduced was to address this problem.  The (almost complete)
version model will detail how this is done, but the goals
document provides the concepts that will be used.

   The example describes a user named Joe who began doing some work
   in the "mainline" activity, and a user named Jane who later began
   work on the same versioned resource in a separate "image_updates" 
   activity.  When Joe attempts to merge the activities, "There are 
   a number of places where he added new functions that do not have 
   images as Jane didn't know they were there."  Nonetheless, "Once 
   the changes are complete, Joe checks in the merged version."

   But version-goals-01221999.htm does not make clear where in the 
   is-derived-from graph Joe's merged revision appears.

The new revision resulting from the merge will have the appropriate
two predecessor revisions (i.e. the two being merged), and the new
revision will be marked as being part of the mainline activity
(the current-activity of Joe's workspace).

   Given that
   it lacks some needed images, the new revision apparently belongs 
   at the tip of the branch associated with the image_updates activity.  

I'll stick to the term "activity", to avoid confusion with a
particular underlying branching implementation.  As to which activity
this new revision belongs to, that's Joe's choice.  Joe indicate his
choice by setting the "current-activity" of his workspace.  He has
currently selected the mainline activity, but he could have chosen
the images_update activity, or some new "merge_images_to_mainline"
activity.

   It doesn't yet belong on the mainline branch since not all the 
   image update work has been done.

He could still want the partial work to appear on the mainline activity.
Or not.  That's a choice Joe has to make.

   But once the new revision has 
   been placed in the image_updates branch, Jane can easily see Joe's 
   new functions and add the images they need.

True.

   While this approach does work, I assert it is unfair to Jane.  She 
   completed her work before Joe completed his.  Why wasn't her work 
   added back into the mainline?  She was done, and could have created
   a mainline revision that made her work more publically available.  
   Yet as I understand the system proposed, she could not do this because 
   Joe, by mere virtue of having checked out the file first, claimed the 
   right to check in first as well.

   Did I read the proposal correctly in this regard?

Joe doesn't claim the right to checkin on the mainline activity
because he checked out the file first, but rather because he was the
one working on the mainline activity when he did his checkout.  The
assumption is that he is in the middle of making some consistent
change to the mainline.

If you want whoever gets done first to be able to check their work
into the mainline, then you just make it policy that everyone does
their work in some private activity, and then only work on the
mainline when they are actually doing their merge.  (You certainly
don't want two people trying to merge into the same file in the
mainline at the same time).

Does this address your concerns?

Cheers,
Geoff