Changelist as atomic units (was: [p4] Building without changelists)
Gregg G. Wonderly
gregg at skymaster.c2-tech.com
Mon Oct 1 14:32:44 PDT 2001
>Actually this issue goes hand in hand with a dialog I had not long ago
>with Perforce support.
>What I want do, is to use changelists as an atomic building block for
>many operations, such as synching, labeling, querying about labels.
>I reaalize that implementing this is by no means simple or straightforward.
>I do, however, believe that this is a direction Perforce should take.
>Are there other users that subscribe to my opinion ?
Inside of Lucent Technologies, the 5ESS development project uses an SCCS
derived toolset called ECMS (the name may have evolved). This was richly
integrated with IMRTS which was the defect tracking system (All developed in
house). The Initial Modification Request (IMR) was the thing that the project
tracked. It itemized a bug or a development task. This had an associated
number (123456 for example). ECMS required an IMR number in order to create a
Modification Request (MR, remember that name from the SCCS manpage?). The MR
had a naming structure which included subsystem and load line and the letters
A-Z. Twenty Six MRs per IMR could be opened in a single subsystem. MR
dependencies could be declared inside of a subsystem if they were not physical
dependicies based on changing code changed under another, non-approved (in
that load line) MR. MRs are only approved at release cycles, prior to first
release to the field. After that, dependencies would be declared (after
prompting to abort) automatically if you touch unapproved code with your MR.
Across subsystem dependencies are listed in the IMR. There are two levels
here. First, the IMR submission process requires a set of MRs. The MR
creation tools populate the IMR as MRs are created so that all the correct MRs
are in the IMR based on your work. If you need additional MRs, you can add
those, OR, if an existing IMR covers the dependency, then you add the IMR
dependency at submission time.
This creates an inheritance heirarchy that allows new IMRs to be created to
collect groups of existing IMRs so that various views of the work can be
created and tracked. There are web based tools for view, searching and
otherwise querying the relationships created.
The big thing for me is that IMRs are not closed as MRs are closed. They are
only closed when the entire task is completed.
This is a flexible and powerful mechanism that enables developers to do their
work and provide project managers the information needed to do their work.
gregg at c2-tech.com (C2 Technologies Inc)
More information about the perforce-user