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