Implementing Incremental changes to DAQ Operations scripts

This is a preliminary version of how this "should" happen, since I am just starting to understand it. It should be thoroughly vetted. Leon 2018-01-24

The scripts for starting and stopping applications for the Nova DAQ system are held in the cvs repository. The package is called DAQOperationsTools, and the directory with the scripts is call script. This package should be checked out in a test release. The current version of the scripts that are executed will be in the /home/novadaq/DAQOperationsTools/bin directory. This is a symlink to the test release's executable directory. For example, the current (2018-01-24) test release directory is:


The current /home/novadaq/DAQOperationsTools/bin is a symlink /home/novadaq/testRel_FDOps_20171025a/bin/Linux2.6-GCC/:
bin -> /home/novadaq/testRel_FDOps_20171025a/bin/Linux2.6-GCC

This symlink gets updated to change which test release to use for the operations in a reversible way.
When the novadaq user sets up the environment this will NOT put these scripts in the path.
In order to make changes to the scripts the changes should be made in the cvs controlled script directory. Changes should be committed by the user making the changes. They will have to have a ticket for their own kerberos principal, and commit it with a usefully descriptive commit message.

cvs -d commit "MY_CHANGED_FILE" 

The following will probably NOT work. It looks like the current version of the OPS test release was not created this way. Or possibly it has to be done before doing setup_online. As it is, it looks like it wants to copy to $SRT_PRIVATE_CONTEXT, which is currently R12_00_02. Perhaps running srt_setup -a in the testRel diretory will do the right thing. I need clarification. LMM
When it is ready for use it can be copied to the bin/Linux2.6-GCC directory by running make in the script directory. To make sure that this is the only change that will get picked up, it is encouraged to run

make -n

with the "-n" parameter, which will not execute the copy, before executing the bare make command.

It is also true that the DAQOperationsTools package is part of the base release as well. If the script is not executed directly from ~/DAQOperationsTools/bin/ directory, then the base release version may be used instead, and the changes will appear to have no effect.
It is important to know how and where the script is being called.

If the effort is more involved than slight changes, then starting with a new test release to do the development is the correct thing to do, but for minor tweaks, this is a much simpler process.

It looks like there is a potential for confusion over what files are actually called. I think it might make it clearer for what is in the "operations" release and what is in the DAQ release (i.e. the base release in $SRT_PUBLIC_CONTEXT) if the DAQOperationsTools (and others? that AREN'T needed by compiled DAQ programs) is not part of the base release, so that there are not files in the novadaq user's path that could get accidentally picked up.

Creating a List of DAQ Machines at the Far Detector