tool is able to track which directories are used to hold files in both newer and older baselines, and ideally within and view of the repository.
5 Automated Baseline Definition Support: The CM tool must support automation of baseline definitions using change package definitions/promotion levels, and other related change tracking data. Baseline definition should not be a tedious, manual opeartion.
6 Sharing of revisions across development Releases/Streams: The CM tool should not force copying of all files in order to support a new release or development stream. Instead, fixes made to older streams should apply to newer streams if the file has not yet been modified in the newer stream.
7 Software Bulk-Loading Capability: The CM tool provides a means to load in entire product file sets, or at least to load in larger portions of a product in a single operation, rather than the file-by-file method of 1G systems.
8 Parallel Checkout: The CM tool supports the option of using parallel checkouts within a release or stream. In this scenario, even within a given development stream, the option can exist to permit more than one person to make changes to the file concurrently. Ideally, the CM tool detects when this happens and notifies the user checking in code whenever a parallel checkin conflict arises (i.e. checking in files that have been modified by others since being checked out).
9 Branch Label Management or Equivalent: The ability must exist to clearly label branches to support the CM branching strategy of the project. Whether arbitrary branching is used or stream-based branching, labelling must support all of the branching functions (e.g. parallel checkouts, parallel development streams, promotion levels, build/baseline definitions, etc.). Ideally, first order objects other than branches exist to support most of these functions.
10 Support for Makefiles and Build Scripts: The CM tool not only stores Makefiles and Build Scripts, but also can support creation of these based on the set of files in a product. Often this capability is inherent in the related IDE (Interactive Development Environment) tools.
11 Distributed Build Capability (possibly thru tool integration): The CM tool allows very large products to be built across multiple machines to reduce build times. Ideally, the distribution of compile and link operations is performed automatically by the CM solution.
12 Integration with MS SCC compliant IDEs: Microsoft has defined a "de facto" Source Code Control Interface supported by many IDEs and CM tools. Although this interface has changed significantly over time, CM tools should be able to support the majority of SCC compliant IDEs on the most common versions of the interface. This allows the IDEs to plug in to the CM tools which support the MS SCCI. Note that Microsoft has not declared this a standard.
13 Basic Workspace Support: A 2G tool allows you to populate a workspace easily, to compare the contents of the workspace to a specific view (e.g. baseline) within your repository, and lends support to automating the synchronization of differences found in such comparisons. Ideally the CM tool allows for easy synchronization on a daily basis, but also allows for isolation from changes being deposited to the repository.
14 Integrated Problem/Issue/Task Tracking: Problem tracking must be integrated to the extent that problem reports can be traced against change packages, and the states of these problems can be automatically promoted as change status is promoted. Similarly, other tasks/feature tracking capabilities should be integrated so that full traceability from change packages to "reasons" for the change is possible. It must also be possible to generate reports and queries which can translate from problems/features/tasks to change packages,
About the author
Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at farah@neuma.com
