Re: Branching Scenarios

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Sun, 21 Feb 1999 15:07:11 -0500 

Date: Sun, 21 Feb 1999 15:07:11 -0500
Message-Id: <9902212007.AA03598@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <9901199194.AA919487591@SMTPGwy.MERANT.com>
Subject: Re: Branching Scenarios


   From: Bradley.Sergeant@merant.com

   Now let's look at this without talking of branches.  Can the scenario 
   be described in a pure activity world.  Sure.  Case 1 says that all V1 
   activity changes are intended to be reflected immediately in the V2 
   activity (i.e. the mainline), but no V2 changes are to be seen by V1.  
   This is not imposible to describe.  It's just a characterization of 
   the intention of the activitiy.  Knowing this intention the server may 
   optimize or not.

I think your original scenario phrased this better.  I.e. people working
on V2 want to make sure they get all the bug-fixes from V1.  No need
to mention activity or branch mechanics in the scenario.  You'd probably
want to add "and don't want to do any more merges than they absolutely
have to", and you've probably captured the full scenario.

   CASE1: TEE off mainline
   An activity V1 intends all its changes to be reflected immediately in 
   the mainline, but no other mainline changes are to be seen by V1.  

I would be against this kind of phrasing of the scenario.  It is
phrased in terms of CM mechanics, not user needs.

   The CASE 2 scenario below is already covered in the Goals doc.

   I believe there is a third common case we have not discuss so far.  
   I'll breifly outline it:

   CASE 3: AutoMerge
   Developers wish to work off the mainline, but in separate activities 
   so they are not blocked by others checking out the same resources.  
   However, all checkins are all intended for the mainline.  This may be 
   done by checking in to private activity and immedately merging to the 
   mainline, but subsequent checkouts are desired from the mainline and 
   not from the last checkout(checkin) of in the private activity.  This 
   is because of the desire to pickup the latest changes by others.

Hmmm.  This scenario seems a bit strange.  You can keep working on
something as long as you as long as you don't check it in, but as soon as you
check it in, you have to merge it with whatever else has been happening.
What benefit is achieved by forcing people not to check-in until they
are ready to merge?  (It just means they keep things checked-out longer).

   NOTE: The builtin rule that last checked in revision superceeds the 
   revision selection rule in the workspace when selecting a revision 
   would seem to disallow a direct solution CASE 3 as workspace and 
   activity is currently defined.

The rule is "products of the current activity" take precedence.
How does this interfere with what you have in mind for case 3?
(For a merge, you'd normally switch to a "do-merge-xxx" activity).

   These are the only three types of activities I could come up with.  
   CASE 2 is clearly supported by Activities.  I believe the other two 
   cases may require some refinement of the model.  So please include 
   them as scenarios and we can work out the model and protocol to 
   support them as time goes on.  Ok?

I'm happy with the first two (with the branch mechanics removed),
but I'd need to hear more about the third before being comfortable
with it as a scenario.

Cheers,
Geoff