Changelists and Propagation of them

Hi,

suppose this scenario:

A developer collects its logical related work in a changelist. Once he/she
is through with the work he/she submits the changelist. The changes then are
visible to all other developers. The changelist is closed, that is no more
check-outs and changes can be done using this changelist. 
Some time later all relevant changes shall be propagated to a consolidation
code base. To get this done the relevant closed changelists will be
propageted.

In terms of DeltaV a changelist would be an activity. The code bases for
development and consolidation would be workspaces.

Implementation of the process using DeltaV:

1.Choice
used features: workspaces, activities (no baselines used here)
In this implementation an activity must only contain working resources of
vcr's of one workspace (in diffrence to the deltaV draft, but this behavior
is within the boundries of deltaV as stateted on this list eralier). Once a
checkin is made on an activity the server will prevent any further
check-outs to this activity. The activity is said to be closed. It is still
in existence to use it for propagation purposes.
The consolidation workspace will be build using MERGE of an activity into a
workspace. (Would MERGE create a VCR in the destination workspace, if it
would not exist, to successfully merge a version of a vcr of the source
workspace into the destination?)
A serious flaw in this implementation is the obvious violation of the deltaV
activity definition.

2.Choice
used features: workspaces, activities, baselines, labels
In this implementation an activity still must contain working resources of
one workspace only. After checkin of an activity the server creates a new
baseline of the workspace (due to the auto-version behavior of the version
controlled configuration). This baseline gets an server defined label (a
unique number of the "changelist") to identify a given changelist later. Due
to the definition of the auto-version (checkout-checkin) behavior every
checked-in activity is represented by a single baseline. To propagate the
changes the labeled baselines are used.
The consolidation workspaces will be created using MKWORKSAPCE with
reference to a baseline of the development workspace. Change propagation is
done with MERGE of a baseline into destination.
Problems here: 
a) How could a client get the server generated number of the changelist?
b) To be precise an activity is not realy represented ba a baseline. Instead
an activity is the difference between the baseline created at checkin of the
activity and the direct predecessor baseline. But if the server does a
difference storage of baselines this is no problem. A problem is the fact
that a merge of a baseline means a merge of the complete baseline. Resources
will be merged that are not part of the activity. And thats clearly not the
thing thats meant by propagating a changelist. The latter would be achieved
by the propagation of the diff instead.

So you see me a little confused. How to achieve the behavior I have in mind.
But maybe I oversee the easy way. Maybe there is just a little change in the
process and everything falls into place easily instead.
So whats your experience concerning this process? Any hint is highly
appreciated.

Thanks in advance
Daniel

Received on Saturday, 9 February 2002 07:22:05 UTC