OPB Tools Maintenance Notes

Last Modified: November 4, 2014 by Tony Roman

CVS

The code for all of our tools is maintained in a CVS library. (I think CVS stands for Concurrent Version System.) CVS is a version control system that keeps a history of all changes made to the files that it manages. (PLib is a CVS library.)

In order to use CVS, you must first define the CVSROOT environment variable to point to the CVS repository that you want to use. To work on our tools, CVSROOT should be set like this:

setenv CVSROOT $DATA_DIR/cvs

You might want to put this line in your .setenv file.

CVS allows multiple software systems to be maintained in the same library by separating different software into different modules. For example, the CVS library that APSB uses has one module for Trans, one module for Spike, one module for APT, etc. The CVS library that we use has two modules: bin and cgi. Most of our tools are in bin, but cgi scripts that run on a web server are located in the cgi module.

CVS has many commands to perform many different functions, but there are only a few commands that we need to use:

      cvs checkout
      cvs commit
      cvs update
    

Once you have CVSROOT defined, cd to a good local working directory (e.g. /data/hera1/royle) and type:

cvs checkout bin

This will create a complete copy of the bin module on your local disk. It will be in a new subdirectory called bin. This provides your own local copy of our tools for you to change. You can also test those changes locally without changing the operational version of the tools.

When you are finished testing your change and everything looks good, you can commit your changes into the CVS library. To do this, cd to the parent directory of your bin directory and type:

cvs commit -m "A short comment about what changed." bin

This will commit all changes to that you made to any file. If you made changes to several file but you only want to commit a particular file's change, type:

cvs commit -m "your comment" bin/your_file

Also, you can omit the -m option and cvs will give you an editor into which you can type your comment.

Sometimes, when you try to commit you will get an error that says that your local copy is not up to date. This means that someone else has committed some changes that you do not have in your local copy. Before you can commit, you will need to:

cvs update bin

This will update your local copy. It will not erase any changes that you have made in your local copy. Once you have updated, then you can retry your commit; and it should work.

Releasing to the Operational Environment

After you have committed your change in CVS, the next step is to release that change to the operational environment. We have our own tool for doing that. First, cd to the directory above your local copy of bin or cgi. Next, run the release command:

release bin/<filename1> bin/<filename2> ...

SpecTcl

All of our Tcl/Tk GUI code files are written and maintained by a GUI builder called SpecTcl. SpecTcl is a GUI for making GUIs. It takes your input and writes all of the GUI code for you. SpecTcl has a great built-in tutorial. To start SpecTcl, just type:

specTcl

To run the tutorial, click on the Help menu, select Help Contents, and then select SpecTcl Tutorial. When you need to edit one of our GUIs, you will find all of the files in the gui subdirectory of the bin directory.

IMPORTANT: Tcl files created by specTcl must not be modified by anything other than specTcl.

utilities.tcl and ops_utilities.py

The files bin/utilities.tcl and bin/lib/python/ops_utilities.py contain many procedures and functions that are used by more than one tool. It would be a good idea to look at these files before doing anything else so that you become familiar with the utilities that we currently have. This may save you from having to reinvent the wheel.