Laserfiche WebLink
duplicate files; however, if performance and convenience is limited, then a different approach can be <br />taken. The main reason for archiving all code at RTi during development is to ensure that only one <br />copy of the code is edited at any time. A single master copy of all code should be maintained using <br />the guidelines set forth by the development team. <br />Comments about the Briefing Room prototype are noted (see Task Memoranda 1.05-2 and 1.05-27) <br />but are not immediately addressed on the Briefing Room machine. It is inefficient to react to each <br />suggestion and bug, especially with all of the maintenance procedures that need to be used to <br />maintain a large system. Improvements to the prototype will be incorporated at regular intervals. <br />Improvements that can easily be addressed will be incorporated into the next revision of the <br />prototype. Improvements that require extensive development will be noted, and reviewers will be <br />told that such improvements are in progress. <br />Product Updates <br />The CRDSS software products are packaged separately so that software updates can be easily <br />tar gzip <br />performed. The and programs are used to create a single compressed ?tar? (tape archive) <br />crdssmakedist crdssup <br />file that contains many directories and files. The and programs have been <br />developed to aid in product distribution. RTi uses this method to package into a single distribution <br />file all files associated with a software product. RTi suggests that the distinct software products be <br />packaged using this method so that updates consist of: <br />(1)Packaging the product. <br />(2)Copying the ?package? from RTi to the Briefing Room machine. <br />(3)Installing the ?package? software. <br />Implementing these distribution procedures in Year 1 will facilitate distribution of the CRDSS <br />software to remote sites in later years of the project. <br />Multiple Code Versions <br />Several developers may work on related CRDSS components at the same time. Consequently, <br />provisions must be made to prevent one developer's efforts from interfering with another's. At the <br />file level, only one user is permitted to edit a file at any time, and revision control is used for all code <br />(see Task Memorandum 1.05-20). Multiple developers editing the same file should not be an issue <br />because, in general, the work division on the development team will result in only one person being <br />assigned to work on any file. If a file is corrupted, it can be retrieved from a daily backup tape (see <br />Task Memorandum 1.05-24). Using the CVS revision control software also ensures file integrity. <br />Because software libraries are used extensively in the CRDSS, it is possible that one developer could <br />adversely impact another developer's efforts by changing a library routine. For example, one <br />developer could edit a library routine and ?break? it. Other developers who depend on the library to <br />complete their efforts would then be unable to finish their work. This type of problem is especially <br />frustrating when the dependent developers do not realize the problem and assume that it is their code <br />that requires debugging. <br />3 <br />A275 01.08.95 1.05-22 Malers <br />