Re: Some configuration management scenarios

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Wed, 24 Feb 1999 17:09:16 -0500 

Date: Wed, 24 Feb 1999 17:09:16 -0500
Message-Id: <9902242209.AA05977@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: Bradley.Sergeant@merant.com
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <9901249198.AA919897271@SMTPGwy.MERANT.com>
Subject: Re: Some configuration management scenarios

   From: Bradley.Sergeant@merant.com

   Ok, now I see how your scenario 3 will work.  We don't need P1R1, it 
   only serves to indicate a change in the P1 project's RSR to run off a 
   fixed configuration rather than a latest label.  Make sense?

Yes, exactly.

   Also, if we remove the #2 buildin selection rule in workspaces and 
   rely on the RSR rule then my other concerns go away and things get 
   simpler.

Great!

   Thanks for clearing this up.

Here's what I've currently got for the amended CM scenario list:

-----------------------

(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).


(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.1-B) A branch-based system is used. 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.

(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.


(3) At some point project P1 produces a configuration C1.  Project P2
is now started, based on C1.  A workspace, Workspace-P2, is created to
generate the series of configurations for P2, and Workspace-P1 is
renamed Workspace-P1-C1.  An activity is either done for the P1-C1
project (performed in or merged into Workspace-P1-C1) or for the P2
project (performed in or merged into Workspace-P2).

(3.1) Any bug-fix activities for P1-C1 should be incorporated into the P2 
project (be merged into Workspace-P2).

(3.1-B) A branch-based system is used.  All P1 activities have their
DAV:branch property set to branch-main.  After P1 produces a
particular configuration, C1 (e.g. corresponding to a product
release), a new project, P2, is started based on C1.
All P2 activities have their DAV:branch property set to branch-main,
and all P1 activities now have their DAV:secondary-branch property
set to branch-P1.

The effect of the DAV:secondary-branch is that this branch is used
when a revision is checked out that already has a branch-main successor.
Then when a P1 activity is merged into Workspace-P2, only versioned
resources that have a branch-P1 branch need to be merged (the others
were effectively automatically merged on checkin).