Re: Branching Scenarios

Geoffrey M. Clemm (
Sun, 21 Feb 1999 13:37:46 -0500

Date: Sun, 21 Feb 1999 13:37:46 -0500
Message-Id: <9902211837.AA03560@tantalum>
From: "Geoffrey M. Clemm" <>
In-Reply-To: <> (
Subject: Re: Branching Scenarios

Suppose we defined a DAV:branch property that can be assigned to an activity.
This is just a way for a client to say what "branch" they want products of
that activity to go on.  A server can just ignore this property, if it doesn't
support or isn't interested in branches (e.g. a change-set system).

Let's see how this plays out against Brad's scenarios:


	Case 1: Version V1 of a product ZOO has reached its feature complete 
	milestone (FC), which for this project means it has all its intended 
	features, but still has bugs to be fixed.  At this point some 
	developers will continue fixing bugs in version V1, but others will 
	move on to work on the next version (V2).  The V1 code is on the 

So V1 activities had their DAV:branch property set to "mainline".

        Because further changes to V1 are intended to be minimized 
	and the V2 work is a natural evolution of the V1 work, V2 work will 
	continue on the mainline.

So V2 activities will have their DAV:branch property set to "mainline".

        Also, it is important that all bug fixes 
	for V1 also be immediately reflected in the V2 work.  So V1 bug fixes 
	also will be reflected on the mainline.  If a resource needs to be 
	changed for a V1 fix and it has already been fixed modified on the 
	mainline for V2, then the V1 change is made on a branch and also on 
	the mainline.  Otherwise, if no V2 changes have yet been made to the 
	resource the V1 change is only made on the mainline.  Thus the V2 
	version of ZOO is just the tip of the mainline, whereas the V1 version 
	must be obtained from a fixed configuration (via a fixed label, or 
	whatever mechanism is used) and this configuration must be updated 
	with each bug fix to V1.

A simple approach is to just set the DAV:branch of V1 bug fix
activities to be "V1-bug-fix", and then require that all V1 bug fix
activites be merged to the mainline.  Then the RSR for V2 is just
and the RSR for V1 is just
   LATEST(V1-bug-fix) else V1-Config

This produces the effect you want, but isn't *identical* to the branching
you describe above.  To produce something identical, you could just add
another property, say DAV:secondary-branch.  Then you would set the
DAV:branch of a V1 bug fix to be "mainline" and the DAV:secondary-branch
to be "V1-bug-fix".  Your server would put things on the DAV:branch if it
could, and otherwise put it on the DAV:secondary-branch.  In this case,
the RSR for V1 is more complicated (to capture the changes you made on the
mainline that are for V1).  Because of the resulting complication in the
V1 RSR, I'd recommend the first approach, but that's up to the user/client.

	Case 2: Version V1 of product ZOO has been released and version V2 
	development is well underway.  A key customer has contracted to have a 
	specific enhancement made to V1 specifically for them, the resulting 
	version is referred to as V1-A.  The V1-A enhancement is superseded by 
	different features that will be available with the V2 release, but the 
	customer does not wish to wait for V2 to complete.  All work on V1-A 
	will not be used in V2.  Therefore all V1-A changes are made on 
	branches newly created just for V1-A.

Just set the DAV:branch property of V1-A activities to be the "V1-A".

	I don't see how this can be done without some indication being given 
	as to which branching policy is desired for each Activity.


        Such an 
	indication could be in the form of a property on the Activity or an 
	option in the creation of the activity.

We've got a fine extensibility mechanism in the form of properties ...
I say, use it.  What else would the "option on creation" map to?  You
could try to bundle all this into the "resource-type" property, but I
see no reason to do so.

        Alternatively or in addition, 
	an administrator might specify which branching policies were allowed 
	for a set of resources. The indication of which policy to use could 
	be abstract and general, e.g. Principle vs. Supporting activity.  Or 
	the indication could be an implementation specific property.  A third 
	idea would be to see if a few specific types of activities could be 
	defined to meet known needs and leave the door open for adding new 
	ones later.

I believe there are just two suggestions here: have this additional information
stored in the resource-type, or store it in new properties.  The latter seems
far more flexible, with no disadvantages, so I'd vote for that.

	None of these choices fills me with glee.  I'm probably missing 
	something.  Help me out.

What's wrong with a couple of conventional properties, that allow a client
to store a choice in a standard place accessible by interested clients and