NAIUA: OpenROAD SIG

Interfacing OpenROAD to Source Management Systems

Source management systems typically manage revisions of text files. OpenROAD maintains its source repository in a relational database, and the OpenROAD development tools operate only on the source in the database repository.

OpenROAD applications and components can also be exported from the repository as pure text files. Those text files can later be imported into the same (or a different) database to reconstitute the original application or component.

It is very easy to export an entire OpenROAD application as a single text file, but this is generally useful only for archival and transport purposes. The resulting text file can be quite large and may be difficult for a source management system to handle. It is also very difficult to visually interpret the differences between one revision and the next. When the scope is an entire application, the differences can be voluminous.

On the other hand, storing text-file representations of individual application components (component export files) is quite reasonable. Component export files provide a way to archive OpenROAD source in an external source management system, and to use that system to track changes. In fact, the OpenROAD development group manages 4GL source this way.

Component Exports

Although component export files are text files, they contain a textual encoding of binary object data, and for the most part are not easy for a person to interpret. Small changes to the original source can result in a large number of differences in the exported text files. However, the text of procedure and frame scripts can be clearly seen amid the encoded structures, and changes made to those 4GL scripts are visible as simple textual "diffs" between export files.

The most practical way to manage OpenROAD source is to export each component as a component export file. Those text files can then be checked into an external source management system. Tracking changes at the component level provides a practical level of granularity for change control.

Using this approach, the database repository is considered to hold the "work in progress," while the source management system holds the "official" source as text files. To make a change, you would reserve the export text file in the source management system, edit the corresponding component in the database using the OpenROAD Workbench, export the modified component back to the file system, and finally check that new component export file back into the source management system. Using this approach, any changes made to the 4GL text of procedures or frame scripts can be seen quite clearly as differences between the versions of the component export file.

This approach requires discipline. Every time a developer changes an application component, the developer must be sure to export the modified component, and check the component export file into the external source management system. However, there is a substantial payoff: storing the application components in an external source management system not only provides a mechanism for tracking changes, it also provides an archive from which an entire application can be reconstituted. If the source management system provides a mechanism for saving a snapshot of the current state of an application, it also provides a method of recreating earlier versions of the application. Users can easily create a batch file or shell script that will import component export files into an application in the database repository.

Getting Started

Once the components of an application have been stored in a source management system, keeping the source management system up to date is a simple manual process. However, the initial step--exporting all the components of an application so that they can all be checked in to a source management system--is not a task that the OpenROAD Workbench is designed to handle.

The OpenROAD development group has an OpenROAD application that will export all the components of an application to a specified directory. This application is designed for our development environment, but it will be easy to provide a generic application that OpenROAD users can use to export all the components of an application.