Branching Scenarios

Bradley_Sergeant@intersolv.com
Fri, 12 Feb 1999 14:35:55 -0500 

From: Bradley_Sergeant@intersolv.com
Date: Fri, 12 Feb 1999 14:35:55 -0500
Message-ID: <0028AFBF.@intersolv.com>
To: ietf-dav-versioning@w3.org, jamsden@us.ibm.com
Subject: Branching Scenarios

     I'm interested to see how two commonly used branching 
     techniques/policies would be accomplished using the proposed WebDAV 
     versioning model.  I'll outline the ideas and describe the basic 
     scenarios.  I'll describe the scenarios using software development 
     nomenclature and assume use of a branching SCM system. The topic of 
     this post is if and how such scenarios would be supported assuming 
     they apply to web content management. 
     
     Note that both Case 1 and Case 2 represent SCM process choices that 
     are commonly used.  For good or bad they represent two ways that 
     parallel development is managed at Company X.
     
     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 
     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.  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.
     
     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.
     
     So, how would a WebDAV server that supports versioning (using the 
     current proposal) support these two cases?
     
     TRY1: An ACTIVITY is directly related to a branch.  Creating a new 
     activity means creating a new branch.  This branching policy supports 
     case 2, but I don't see how it can easily support case 1.  In Case 2 
     the desire behavior is obtained by continuing V2 using the V1 Activity 
     and creating a new activity for V1-A.  In case 1 the V2 activity does 
     not want to create a new branch, so it must continue to use the V1 
     activity.  Then V1 bug fixes would have to go into a new activity 
     forcing a new branch with every change, but is just case 2 and does 
     not match the branching policy of case 1.
     
     TRY2: An Activity uses the following branch policy:
     * if the selected revision to be checkout is the latest then check it 
     out on the same branch it is on.
     * if the selected revision is not the latest, then check it out on a 
     new branch associated with the activity.
     
     The TRY2 branching policy works for Case 1.  The V1 activity continues 
     to be used even after the V2 activity is created.  Only resources that 
     have been modified by V2 cause V1 to branch.  Because V1 does not work 
     off of latest, it will not cause V2 to branch, but all changes to V1 
     on the original branch will be picked up by V2 and non of the others.
     
     However TRY2 does not provide the desired behavior for CASE 2.  
     Creating a new Activity for V1-A does not necessarily result in a new 
     branch.
     
     Understand, the point here is not to find some way to manage cases 1 
     and 2 using the Activity mechanism, but to find a way to do it and 
     preserve the branching policies of Company X.  This is important to 
     Company X because they want to continue using their SCM procedures and 
     have their new WebDAV server fit into this existing system.
     
     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. 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.
     
     None of these choices fills me with glee.  I'm probably missing 
     something.  Help me out.
     
     --Sarge