Checking files back in

After files have been modified, they must be re-entered into the database. To do so, the user first selects the relevant files from the main display of the versions program and selects the Checkin button.




Since the user must have already checked out a file, many of the fields on this form will be familiar, and don't warrant a repeat discussion.¹ The commentary fields (Title and Description) as well as the issues list may be modified at this time. There are a few extra elements to the check-in effort though that do require some explanation.

As files are being checked back into the database, the user has the option of either having the edited copies removed completely from the directory, having read-only copies left in their place, or of directly checking the files back out again for edits. The preference is made in the upper right section of the form. The latter case of doing an immediate re-checkout is a convenient mechanism for checkpointing efforts into the database prior to a new wave of edits.

Razor normally keeps a backup file associated with each file that is checked out or introduced (consistent with Razor's philosophy of "better safe than sorry"). This behavior is controlled by an Xdefaults setting described in "Versions.makeBackup" on page 285.

As the files re-enter the system, the minor version number of each file will be incremented. For example, a file that was at 1.22 will now be at 1.23. Local conventions may suggest that you occasionally increment the major number of the files. Selecting the Increment release number toggle will cause all of the files to resequence to the next major release number. In other words, a file that was at 1.22 will now be at version 2.1.

Checking in multiple files

When multiple files are being put back into the system at the same time, the user has the option of either having the same Title, Description, and related Issues be associated with all of the files, or have the original commentary from the various check-out efforts be recycled for the check-in. This is controlled through the Use toggle in the middle of the display.

TIP: When multiple files are being checked back in, the comments from the first in the list are offered to the user on the check-in panel as a reminder of why the files were checked out in the first place. Highlighting different files in the scrolling list in the upper left of the display will cause the Title, Description, and Issues information to update accordingly.

Forcing files to be changed on check-in

An Options file may be added to the Tables directory of a versions group and/or to the Tables directory of the database. This file can be used to gain more control over the check-in process. A check-in operation can permit no change to the file, warn the user if there is no change in the file, or require a change before the file is checked in. See "Options" on page 202 for details on the file format and usage. A dialog like this one will appear when the file is checked in. Selecting More Info... will display more detailed information like the dialog in the lower right.

NOTE: Occasionally, access to a checked-out file is required by someone other than the original user. Users defined in the RAZOR_ADMIN role (see "Definable roles" on page 201) have permission to check a file back in or uncheck it. This provides a work-around when a key implementor left a file checked out and went on vacation.

¹ You are, of course, free to go back and look... see "Checking files out for edit" on page 87