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 mailing list