Re: Some configuration management scenarios

Bradley.Sergeant@merant.com
Wed, 24 Feb 1999 08:33:48 -0500 

Message-Id: <3.0.5.32.19990224083348.02ba9100@127.0.0.1>
Date: Wed, 24 Feb 1999 08:33:48 -0500
To: ietf-dav-versioning@w3.org
From: Bradley.Sergeant@merant.com (by way of "Ralph R. Swick" <swick@w3.org>)
Subject: Re: Some configuration management scenarios

     The terminology takes some getting used to, but I can see the 
     correlation's.  Scenario 3.2 may indeed correspond to my scenario 1, 
     but you did not include it in your mail.  I don't quite see it easily 
     emerging from 3 or 3.1 so I'll call it 4 for now.  The basic idea was 
     the continuance of an existing line of development for future work and 
     the creation of a dead-end activity for limited changes to a release 
     (patches), while merging all changes into the continuing development 
     as well.
     
     (4) Project P1 releases and creates configuration R1.  Future 
     development continues as before for P1.  The "end game" for R1 is 
     referred to as the P1R1 project.  Any incremental "patches" to release 
     R1 are done in or merged into the P1R1 workspace.  Configurations for 
     the release of P1R1 are generated from the P1R1 workspace.  All 
     changes made in or merged into P1R1 are also merged into the P1 
     workspace.
     
     (4.1) A branch-based system is used. P developers are required to work 
     on the same branch (the DAV:branch property of all P1 activities are 
     set to be "branch-P1").  P1R1 developers use the branch-P1 if 
     possible, otherwise use the "branch-P1R1" (by setting the DAV:branch 
     property of P1R1 activities to branch-P1 and the DAV:secondaryBranch 
     property to branch-P1R1).  This way only P1R1 changes that occur on 
     resources already modified by P1 activities go on the branch-P1R1.
     
     Geoffrey, from the point of view of the branching system no merge is 
     required for P1R1 changes that go on the branch-P1.  In your current 
     protocol proposal would a merge be required in order to update the P1 
     workspace to see the P1R1 changes that were made on the branch-P1?  Or 
     will the RSR of the P1 workspace make this unneeded?  I'm thinking a 
     merge may be required, but might not result in any change to the 
     revision histories of the versioned resources.  This would be because 
     a preexisting P1 activity had previous checked in an ancestor of a 
     resource modified on branch-P1 by a P1R1 activity and the built-in 
     activity RSR rule #2 would cause an earlier revision to be selected.
     
     Sorry for the convolution.  I'm trying to understand the implications 
     of the proposed protocol on branching systems.  (I don't have a 
     problem requiring the merge.)
     
     --Sarge

______________________________ Reply Separator _________________________________
Subject: Some configuration management scenarios
Author:  "Geoffrey M. Clemm" <gclemm@tantalum.atria.com> at SMTPPOST
Date:    2/23/99 11:04 AM


     
Here are some scenarios that are intended to capture (and extend) the 
3 scenarios Brad described, but in a "branch-neutral" fashion (except 
for 1.3, which is explicitly a branch-based scenario).
     
Brad: Please check to see if I've accurately captured the scenarios 
you had in mind.  In particular, I believe 3.2 is your scenario 1, 
3 is your scenario 2, and 2 is your scenario 3.  (I reordered them 
to make the "simpler" scenarios first, which hopefully doesn't just 
cause confusion :-).
     
     
(1) There is a project, P1, that produces a series of configurations 
(there is an identified workspace, Workspace-P1, that produces
new configurations for P1).  There can only be one checkout of a 
versioned-resource at any time, and each developer wants to see the 
same resources, including working-resources, as every other developer 
(every developer uses Workspace-P1).
     
This is the "chaos with history" scenario (:-).
     
(2) There is a project, P1, that produces a series of configurations. 
Each developer on the P1 project wants to work on his activity in 
isolation (in a personal workspace), and will merge the completed 
activity into the project (into Workspace-P1) when it is ready to be 
seen by the other developers.
     
(2.1) New activities must be based on the current state of the project 
(the contents of Workspace-P1).
     
(2.2) New activities must be based on the most recent configuration of 
P1 (the most recent configuration produced by Workspace-P1), rather 
than the current state of P1.
     
(2.3) To minimize merge conflicts when merging into Workspace-P1, 
a developer merges the latest configuration from Workspace-P1
into his personal workspace before merging his activity into Workspace-P1.
     
(2.4) A branch-based system is used, and all P1 developers are 
required to work on the same branch (the DAV:branch property of 
all P1 activities are set to be "branch-P1").  This ensures that 
only a single branch exists for all versioned resources, and 
requires a "merge" before CHECKIN for any resources that have 
been checked-out in parallel.
     
     
(3) There are two projects: P1 and P2 that each produce a series of 
configurations (from Workspace-P1 and Workspace-P2 respectively).  The 
P2 project was based on a configuration from the P1 project.  An 
activity is either done for the P1 project (performed in or merged into 
Workspace-P1) or for the P2 project (performed in or merged into 
Workspace-P2).
     
(3.1) Any bug-fix activities for P1 should be incorporated into the P2 
project (be merged into Workspace-P2).
     
     
Cheers,
Geoff