Re: Some configuration management scenarios

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Wed, 24 Feb 1999 12:02:12 -0500


Date: Wed, 24 Feb 1999 12:02:12 -0500
Message-Id: <9902241702.AA05842@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: Bradley.Sergeant@merant.com
Cc: ietf-dav-versioning@w3.org
In-Reply-To: <9901239198.AA919833263@SMTPGwy.MERANT.com>
Subject: Re: Some configuration management scenarios


   From: Bradley.Sergeant@merant.com

   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.

Ooops.  I meant to say that (3.1) corresponds to your scenario 1.

   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.

My scenario (3.1) was intended to capture this situation.  So let's
see if there are any differences between (3.1) [quoted below] and
your scenario (4).

   (4) Project P1 releases and creates configuration R1.  Future 
   development continues as before for P1.

We're in synch so far.

   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.

In my scenario, I didn't create a new project name or workspace for
P1R1, but just kept calling them P1.  So if in scenario (3.1) you
rename the workspace Workspace-P1 to be Workspace-P1R1 immediately
after the configuration R1 is created, then I believe scenario (3.1)
and (4) are equivalent.  If doing this rename makes the scenario clearer
(and I can see how it might), then I'm all for it.

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

Yup, that works for me.  So let's number this scenario "3.2".
(I've added it to the scenario document I've started ... I'll hand
it over to Jim as soon as it settles down).

   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?

The protocol doesn't currently define a MERGE method (I was going to
wait until we had agreement on the workspace and activity concepts),
but looking ahead, yes, I believe the protocol should provide a
MERGE-ACTIVITY method.  The actual implementation of the MERGE-ACTIVITY
method would then be up to the server, and would vary depending on
whether the server is branch-based, change-based, or whatever.

   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. 

Yes, if the DAV:branch of the activity being merged is
currently specified in the RSR of the destination workspace, then the
server knows that no resource merges are required to achieve the
activity merge (it was effectively done as soon as the new revisions
were checked-in).  If the activity has a DAV:secondary-branch, then the
server would have to do a merge from that secondary-branch, if it
exists on a versioned resource.

   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.

Aha!  Now I see the concern you expressed earlier about having the
DAV:activity be built-in high priority rule.  It would have to be an
"and" rule (i.e. let later rules extend the revision selected to a
descendent), but many servers only support "or" rules (i.e. if you
find a match in that rule, don't look at any more rules).

JimA: I believe this means we should remove the second built-in rule,
which means that the only built-in rule is that the working resources
in a workspace take precedence over the revision selection rules
(that's a built-in rule I'm sure of :-).  (Jim, we'll probably need
to discuss this on the phone).

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

No apologies allowed!  These were all excellent points.

Cheers,
Geoff



   ______________________________ 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