Re: Some configuration management scenarios
Chris Kaler (ckaler@microsoft.com)
Tue, 23 Feb 1999 10:20:33 -0800
Message-ID: <4FD6422BE942D111908D00805F3158DF0A757E1B@RED-MSG-52>
From: Chris Kaler <ckaler@microsoft.com>
To: "'Geoffrey M. Clemm'" <gclemm@tantalum.atria.com>,
Date: Tue, 23 Feb 1999 10:20:33 -0800
Subject: RE: Some configuration management scenarios
Wouldn't the "chaos with history" scenario be the one where you have a
project where multiple people can checkout the same versioned resource and
checkins are versioned, possibly with client merge, but at a minimum, last
one wins?
Chris
-----Original Message-----
From: Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
Sent: Tuesday, February 23, 1999 8:04 AM
To: ietf-dav-versioning@w3.org
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
Workspace-P2).
(3.1) Any bug-fix activities for P1 should be incorporated into the P2
project (be merged into Workspace-P2).
Cheers,
Geoff