Laserfiche WebLink
> +'IS IMAGINARY') ABNORM <br />> 9030 FORMAT(//' ERROR ABNO003 INSUFFICIENT RESERVOIR CAPACITY') ABNORM <br />> 9040 FORMAT(//' ERROR ABNO004 MINIMUM RELEASE CONSTRAINT VIOLATED ' ABNORM <br />> +'IN MEETING POWER DEMAND') ABNORM <br />> 9050 FORMAT(//' ERROR ABNO005 RESERVOIR RELEASE IS NEGATIVE IN ' ABNORM <br />> +'MEETING CAPACITY CONSTRAINTS') ABNORM <br />> 9060 FORMAT(//' ERROR ABNO006 ITERATION FOR HYDROLOGIC BALANCE IN ' ABNORM <br />> +'SUBROUTINE RESBAL EXCEEDS THE MAXIMUM') ABNORM <br />> 9070 FORMAT(//' ERROR ABNO007 SOLUTION OF QUADRATIC FOR GROSS ' ABNORM <br />> +'POWER HEAD IS IMAGINARY') ABNORM <br />> 9080 FORMAT(//' ERROR ABNO008 GROSS HEAD EXCEEDED MAXIMUM HEAD IN ' ABNORM <br />> +'PREVIOUS TIME FRAME') ABNORM <br />> 9090 FORMAT(//' ERROR ABNO009 IN SUBROUTINE RESBAL, THE FIRST ' ABNORM <br />> +'ITERATION MAY NOT REQUIRE A RESERVOIR RELEASE') ABNORM <br />The way that revision control can handle this situation can be explained using the ?abnorm.f? <br />subroutine as an example. The first step is to make sure that the source code modules have the same <br />line length. Consequently, files equivalent to [original80] and [modified] will have to be generated <br />(using steps as described above) for each code module. Next, put the [original80] file under revision <br />control, saving a comment for the revision like ? Original CRSM code from USBR.? Additional <br />comments can be saved when each new revision is stored. All revisions are stored in the same file. <br />The revision control software can recreate any revision from the information in the file. Revisions <br />are handled by embedding revision control commands within the text of the file. <br />In order to store the State's version of the CRSM code as the first revision, perform the following: <br />(1)Store the 80-column [original80] file version. <br />(2)Check out the file for editing. <br />(3)Replace the editable file with the SEO [modified] version. <br />(4)Check in the file as a new revision. <br />When the file is checked in, the revision control software will compare the previous revision with the <br />revision that is being checked in and will insert appropriate ?insert? and ?delete? commands in the <br />revision control file. Once this step is completed, the revision control file contains the original code <br />and all revisions made by the SEO. Additional changes will result in new revision numbers (but <br />revisions can be combined, if desired). <br />only <br />The editable source file contains the current working copy. Consequently, comments in the <br />code should only be applicable to the current revision. General comments can be attached to a <br />revision to quickly summarize overall changes to a file, e.g., ?Changed all WRITE statements--.? <br />Placing a New File Under Revision Control <br />It is unwieldy to immediately place a new file under revision control because such a file is generally <br />short and will only be added to for a period before it begins to undergo revisions. RTi suggests the <br />guideline that developers place a file under revision control after they have finished the initial <br />keying-in of the file, even if this takes several days (code will be backed-up using the procedures <br />described in Task Memorandum 1.05-24). If the file is placed under revision control too soon, then <br />revisions consist of a large number of inserted lines which would have been added regardless <br />(additions are not a revision, but simply additions to complete the initial version of a file). <br />7 <br />A275 01.08.95 1.05-20 Malers <br />