Some configuration management scenarios

Geoffrey M. Clemm (
Tue, 23 Feb 1999 11:04:25 -0500

Date: Tue, 23 Feb 1999 11:04:25 -0500
Message-Id: <9902231604.AA05132@tantalum>
From: "Geoffrey M. Clemm" <>
Subject: Some configuration management scenarios

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

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