Changing your mind

Although the linear evolution of information in a file may be a nice goal, it is seldom obtainable in practice. The straight check-in, check-out actions described above result in a flow similar to the one diagrammed below.




In the following sections we will explore some variations to that flow.

Uncheck-out files

It is frequently the case that a person will check out one or more files for modification, and later decide that more files were checked out than were really needed, or that the edits were not worth putting back into the database. In this case, the affected files would need to be unchecked. Doing so frees the permission lock on the files without incrementing the version number, or affecting the file archive.

To do this, the user simply selects the files checked out from the main display list and selects the Uncheckout button. A small popup will appear.




The user will have a choice that the file remain where it was, or have it replaced with a read-only copy of what it looked like prior to the check-out. It is assumed for this action that the file has not been moved from where it was checked out to.

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.

Reverting files

Occasionally, a situation may occur where modifications were made to a file, and you wish to back them out. In effect, you'd like to revert to a prior version of a file and pretend that the edits never happened. The Revert option from the Utilities menu allows you to do exactly that.




Rather than delete the intermediate versions and completely lose whatever engineering effort went into them, Razor allows you to take an earlier version of a file and leap-frog it to the front of the evolutionary line.