Laserfiche WebLink
Prototype Tracking <br />Task Memorandum 1.05-20 describes how revision control is used for tracking source code <br />revisions. Prototypes are tracked by assigning different version numbers to prototype components <br />and the complete prototype system. For example, ? CRDSS version 1.0? may contain ?MODSIM <br />version 5.4.? For example, the following file may describe the contents of the CRDSS prototype: <br />CRDSS version 1.0 <br />MODSIM version 5.4 <br />AOP version 2.1 <br />CRSM version 3.3 <br />(etc.) <br />A list of the revision numbers for each file in each prototype is created by scanning the RCS files for <br />the products. Each major product would then have a revision list associated with the product: <br />MODSIM version 5.4 <br />modsim.f revision 1.3 <br />util.f revision 4.4 <br />(etc.) <br />RTi maintains a list of version and revision numbers that are associated w ith the different CRDSS <br />products that are part of the CRDSS. This information is used to define the CRDSS versions and <br />also allows RTi to replace lost files with the correct revision (e.g., from backup tape). <br />Database Considerations <br />Changes in the database structure require that low-level DMI routines (see Task Memorandum 1.05- <br />8) be modified. This requires that applications be recompiled to link in the new DMI library. If the <br />code is not recompiled, then the application is not able to query the database. Consequently, changes <br />in the database design require an immediate adjustment in all applications that access the database. <br />If the Briefing Room prototype CRDSS accesses the database at RTi, then the Briefing Room <br />prototype must use DMI routines that are compatible with the current version of the database at RTi. <br />Changes to the database design are inevitable but will hopefully not happen frequently (multiple <br />design changes could be implemented in a short time period rather than making changes separately). <br />These changes can be handled internally by notifying developers of the change so that they can <br />recompile applications (and link the updated DMI library). Updating the prototype on the Briefing <br />Room machine in similar situations requires that database changes be coordinated with other <br />activities, such as important evaluations using the Briefing Room. Otherwise, a change in the <br />database at RTi could ?break? the prototype on the Briefing Room machine. <br />It may transpire that maintaining the CRDSS database at RTi causes applications running on the <br />Briefing Room machine to not perform well. In such a situation, a copy (or subset) of the CRDSS <br />database will have to exist on the State's database server machine. If this is the case, then changes to <br />the database design at RTi will not require an immediate update of the Briefing Room software. <br />Updates could be scheduled more carefully. This would also allow the database design change to be <br />fully tested before being implemented on the Briefing Room machine. <br />6 <br />A275 01.08.95 1.05-22 Malers <br />