OVERVIEW VERSIONS USERS CROSS-REFERENCES

Double-clicking a Datafile in the main window leads to the file options dialog box -- clicking the INFO button gives the OVERVIEW information. You can access the other categories via buttons on the OVERVIEW window. Or you can directly access these categories via the sub-menu of the DATAFILE menu.

The OVERVIEW includes the file time stamps, Description, Language, the number of references and outstanding locks. The Datafile type (text or data) is shown, along with your allowed access level to the Datafile and your current permissions (via the … box). The Datafile Versions window lists all the versions of the Datafile. If the number of versions exceeds the space, the most recent ones are shown because they are most likely to be of interest, and a vertical scroll bar appears. You can scroll to earlier versions, as well.

If you select a version and click the DETAIL button, CONTROL-CS shows more

information about that specific version.

The Version Detail window lists the User ID of the person who submitted that version, the date/time when the version was submitted, the ‘last modified date/time’ of the file submitted, and the reason for change. If the selected version is locked, the date/time of the lock and the User ID of the locker also appear.

The CONTROL Family of SCM Tools CONTROL-CS The DIFF window uses color to identify added, deleted and modified items. Blank lines are inserted as needed, to keep side-by-side alignment for the lines that matched. Work files on servers or PCs can be accessed by this function.

Another way to show the differences in adjacent versions of text-type Datafiles is the DELTA function of the Versions window. Lines are numbered from 1. Added lines are indicated by a + sign. Deleted lines are show in reverse color, preceded by a minus sign.

The USERS function lists the authorized users of this Datafile and their access level. No access to the Datafile is allowed if the user is not listed. Access level, together with version markers such as ONLINE further limit the versions that a given user can access and the user actions that are allowed. Wild cards, aliases and non- primary groups are supported. (If the Catalog ACL is ‘master’ for access, the Datafile ACL is ignored. Otherwise, both are considered)

CROSS-REFERENCE shows all the Catalogs and Datafiles that reference the selected Datafile. If a particular Datafile is used by several Catalogs, they will appear in the reference list. If one Datafile references another (for example by referencing #include or COPY files) that Datafile name will appear in the reference list. In the example, Datafile COBDDLS is referenced by six Datafiles and two Catalogs. CONTROL-CS updates the cross-references as a by-product of your work. The Cross–Reference list is a way to identify all the Datafiles that include a specific COPY file.

CONTROL-CS implements a "check-out, check- in" model. Extracting a version from the CONTROL-CS archive is easy -- select one or more Datafiles and click the PRODUCE button on the main window. (You can access PRODUCE from the VERSION menu, too.)

The ins.c Datafile has been selected. Note the open folder named ins. Folders allow you to organize groups of files within a Catalog. The ins folder corresponds to a work subdirectory called ins. Also, note the icons that precede the Datafile name. The green arrow means that the associated files are “targets,” that is files that should be compiled. The .h Datafiles ins.h and insy.h are not targets.

Clicking the PRODUCE button on the main window leads to the PRODUCE dialog box. Here you specify the version of the Datafile to PRODUCE (check-out), and the target work file. You also select a "type" of PRODUCE. To get a version, change it and create a new version, choose the FOR EDIT type.

The CONTROL Family of SCM Tools CONTROL-CS Several PRODUCE types relate to "keyword" replacement functions. Suppose that ~F~ appears in a version in the archive. When a PRODUCE (Replace Keywords) is executed on that version, the ~F~ will be replaced by the complete file name of the Datafile. CONTROL-CS also has a "keyword" replacement function that replaces information byte by byte in a binary or "data-type" Datafile. For instance, this function lets CONTROL-CS insert dates, versions, etc. in MS Word files. As CS performs the PRODUCE function, CS “locks” the checked-out version in the Datafile. This "lock" keeps others users from doing another PRODUCE FOR EDIT from the locked version, or from checking in a new version on top of the locked version.

If we check the list of versions of ins.c, the L preceding the version number shows that it is “locked”. The detail view of that version shows the name of the locker and the time of the action.

However, other users can execute other PRODUCE functions on the locked version and can freely work on other versions in the same Datafile.

For instance, a different user can access the same Catalog and same Datafile, then produce the “locked” version to a work area on their PC. (The red color means that the version has been locked by another user.)

At this point you can use CONTROL-CS to launch PC tools to process the work file. CONTROL- CS can detect if the tool you want is already running and avoid starting a second copy. If the work file is on the server, CS brings a ‘shadow copy’ to the PC for you to edit, then returns the updated copy to the server when you close the edit. If the work file is on your PC, it simply starts

your editor. After completing the EDIT phase and saving the changed work file, the user returns to CS, usually by exiting the editor.

Note that because the work file is now more current than the archive, CS shows an “<“ indicator

between the two file names. When you are satisfied with the work file contents, you submit it back to CONTROL-CS to record the new version in the archive. (This is the “check in” step.) You can access SUBMIT from the VERSION menu or by clicking the SUBMIT button on the main window.

The SUBMIT OPTIONS dialog box lets you specify the source work file, the new version and the reason for change. You must provide a reason. Only the user that checked out the version (or an administrator) can check in the new version. CS identifies the changes from the prior version, stores the new version in the archive and clears the lock.

Parallel Development for Emergency Fixes

In the real world, not all development takes place on the LATEST version; sometimes problems come up in production or test that must be fixed. CONTROL-CS allows you to create new versions that are not the LATEST. When a problem occurs in the on-line version, the exact version of the on-line source must be located, the problem must be corrected, the new version must be saved and a revised executable must be made, tested and put in production. When a new version is created and then inserted out of the normal sequence of evolution, we call it an 'emergency fix'.

CONTROL-CS does this via the notion of baselines that we call “releases.” A release usually represents a major event in the history of the file. Suppose that version 1.02 was given to a quality assurance group for testing. At the same time, the developers (or their manager) creates a new release, 2.00. (Yes, versions 1.02 and 2.00 are identical.) This step permits development of the module to continue in Release 2 (making versions 2.01 and so on).

The CONTROL-CS dual numbering scheme allows the module to evolve along several independent paths. While development proceeds on Release 2, changes can still be inserted in

The CONTROL Family of SCM Tools CONTROL-CS Of course, an emergency fix cannot be assumed to be compatible with any release beyond the one it is applied to; the fix made in version 1.03 may be undesirable in release 2. Changes due to an emergency fix version are not carried forward into a later release unless you direct CS to INCLUDE it. However, people working with later releases, (Release 2 or 3 in the example) are warned that an emergency fix was added to the earlier release when they next PRODUCE a version.

It is also possible that CS cannot include the ‘1.03’ emergency fix in release 2 because it conflicts with changes already made in that release. An alternative is to “recode” the 1.03 fix so that it will work in Release 2. But a better idea may be a way to combine the sets of changes, a “merge.” The “check out/check in” model provides the best protection against changes being overwritten and lost. However, there are situations where parallel development from the same point is essential. This means that two or more users begin their work with the same version of a file. One developer completes work and SUBMITs a changed file as a new version. The second developer can’t SUBMIT – the changes in that file might overwrite the changes made by the first developer and some changes might conflict. CONTROL-CS supports this sort of “parallel” development.

A “merge” capability lets CS identify those changes it can blend and the conflicts that it cannot resolve. MERGE detects conflicts, where different changes are made to the same area. The merge function isolates the

differences by comparing the two versions against a “common ancestor,” then comparing the results of the two comparisons. The developers must resolve any conflict detected by MERGE. The “inspect’’ function of MERGE presents tentative

results in a side-by-side display that highlights the lines to be merged by arrows ← and the lines in conflict by color and by X indicators. An example MERGE inspect window is shown below. The user can change the choices made via the Merge SELECT Menu to highlight the lines you want to adjust, then using the Merge CHANGE Menu to alter the Selection Indicator to reflect your choice.

If the required change is too complex, you can use the EDIT WORK menu to lead to an editor. This window provides the ability to edit the work file to address the changes and/or conflicts, within the Merge function. The changes can be saved to the work file or to a different specified file.

Then you can try the merge again to see if the conflicts have been resolved and changes made correctly. Once the merge succeeds, the merged file will be submitted.

The CONTROL Family of SCM Tools CONTROL-CS Launching Tools from within CONTROL-CS

As part of setting up projects with CONTROL-CS, you identify your PC-based tools and server compilers. Then you can launch those tools to act on the work files on your PC with a click or two. By double-clicking a selected file, the file options box appears (or

you can use the DATAFILE menu or WORK menu).

INFO gives the overview information for the selected Datafile. Serv-COMPILE “produces” a file version to the server and invokes a compiler on the server for the language of the selected Datafile. FIND lets you search for strings and/or characteristics in specific Datafile versions.

BROWSE copies a Datafile version to the screen for your review. EDIT invokes the PC editor program defined for the language of the work file.

COMPILE invokes a local compiler defined for the language of the work file.

DIFF compares files/versions and shows the differences. Specifying your Tools within CONTROL-CS

You can specify tools that are used on the client and on the server, for each language, by server, and by project.

CONTROL-CS also uses the MS Windows Registry to select local tools, based on the local work file extension. For instance, the your PC registry may associate the extension .DOC with MS Word. When you select a .DOC work file and click on EDIT, CS can use the registry entry as a guide. Registry entries do not apply to tools to be used for compiles on a server.

The local editor and compiler Client tools can be specified under a Project definition. You access the tool properties via FILE | SELECT PROJECT | EDIT | TOOLS. Tabs on the property sheet are dedicated to a single language. If you want Wordpad.exe to be your default local editor, simply make that entry in the EDITOR box.

If your work files are server-based and you try to edit it by double clicking on the work file, CONTROL-CS will transfer a copy of the file from the server to the PC, make a

temporary copy for you to edit on the PC and then activate the proper PC editor.

The Server Tool Property Sheet interface allows you to define associations between the language attribute of a Datafile and a compiler. You can specify the compiling tools used on a server as part of the server definition. Tabs on the property sheet are dedicated to a single language. You can specify the compiler, the form an object file name takes and items that should be added to the compiler command line.