My system does the following:
Developers use their own development branch. Developers will usually use
one branch for one particular change at a time. They may later reuse the
same branch for a different change or just get rid of it, but at any one
time, they will be using one branch attached to a particular change.
The developer only needs to specify the SCR number once.
When the developer is done, he delivers the change to the integration
branch, which is the same as the build branch. There are a couple of
requirements that need to be met before a developer can do that. These
requirements can be customized to a particular shop's policy, but the
minimum is that the merge into the integrationb branch be a copy merge.
This means that in most cases, the developer is required to merge other
people's changes back into his development branch and resolve conflicts
(do a "rebase" in UCM parlance).
Some shops can specify a review process where the developer simply
notifies the reviewer (often the same person as the integrator), and the
reviewer decides whether to merge into the integration branch or not. I
have tools to assist him, for example a delivery previewer that will dump
a bunch of diff commands to show what the proposed change would do.
I recommend most people not to bother, as in my experience about 95% of
the deliveries are OK, and it is easier to later pull the 5% that is bad
than to restrict communications (and most of the "5%" can be easily fixed
by another delivery).
Internally, I keep track of the change sets via a special file element
that I use as an excuse to attach process hyperlinks and attributes.
Whenever a delivery occurs, I parse the merge log file and attach
"modified" hyperlinks from that special file element to the versions that
have been delivered.
If, at a later stage, I need to yank a particular change, I have a script
that will look at the version of the special element that corresponds to
the delivery I want to yank and generate appropriate subtractive merge
commands to do the yank.
Similarly, I have a "redo" script that will allow a particular change to
be redone on a different branch using selective merges.
I have noticed that the scripts are very rarely used, but that they have a
significant psychological effect. The knowledge that you _can_ yank a
change if you have to enboldens the integrator to let developers deliver
code when they fell ready, and not impose bureaucracy on them.
The special file element has other neat features. Doing an lsvtree on that
file element gives you a nice overview of your whole branching strategy.
as the process guarantees that there will be an instance of every branch
used on the element. It effectively acts like the UCM stream browser.
Labels can be instantly mapped to a set of changes since the last label.
The actual content of the special file can be used to store generated
scripts, for example undo and redo scripts or the findmerge conflict
resolution scripts.
By drawing merge arrows between versions of this special elements, I can
quickly detect whether a delivery requires a rebase, and I can document
merges between different development and integration branches.
Oh, and btw, there is no need to lock the branch while the build takes
place. You only need to lock while delivery or rebase is happening, or for
the time it takes you to instantiate a stable config spec for the build.
Remember to account for time drift over the network when using -time
rules... Once you have a stable config spec, you don't care if other
people deliver stuff while your build is running.
-- cgP.S. I use "deliver" and "rebase" in this post because these are the UCM terms. In my real system, I use "bringover" and "putback", in deference to the teamware codemanager process which I used as my template.
On Thu, 24 Feb 2000, Configuration Manager wrote: > Hi, how would change management/tracking be done in this situation > (ie. CC/CQ integration, systematic baseline creation, change set > tracking, etc...) > > The original poster seemed to want to tie SCRs to file versions and > use SCRs as a basis for baseline creation for the builds, instead of > simply /main/LATEST. > > Mechanically, I can see how what you write below could work. But as > far as change management/tracking, knowing what SCRs are actually > completed, what files version hold there changes, and ensuring the > integrity of the tracking system (are the states of the SCRs really > reflective of where the changes are, in develop, awaiting build, in > testing, etc) I don't fully understand how that can be done in the > process described below. > > I say the original poster is on the right track. Tying tracking > "numbers" to file versions at checkin is the easiest and least > burdonsome on the developer (as opposed to having them create labels > or attibutes manually themselves). And can lay the foundation for > better code and build management stategies and most important, a > fully automated baseline/build/delivery CM system.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This archive was generated by hypermail 2b29 : Sun May 06 2001 - 00:23:26 EDT