Re: Some configuration management scenarios

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Tue, 23 Feb 1999 16:11:03 -0500


Date: Tue, 23 Feb 1999 16:11:03 -0500
Message-Id: <9902232111.AA05383@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ckaler@microsoft.com
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <4FD6422BE942D111908D00805F3158DF0A757E1B@RED-MSG-52> (message
Subject: Re: Some configuration management scenarios

   From: Chris Kaler <ckaler@microsoft.com>

   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?

That I believe corresponds to scenario (2.4), i.e. you each have your
own workspace with your own private working resources, but that you
make things visible to everyone when you checkin.

That is certainly another kind of chaos with history, but it is a
slightly more controlled chaos, because at least you don't see changes
until they are checked in ... in scenario (1) you see changes as soon
as a PUT is done by anyone to a working resource.

Cheers,
Geoff

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