 News |
FAQ
|
| Search
|
Home
|
| Getting Started | Documentation | Glish | Learn More | Programming | Contact Us |
|
| Version 1.9 Build 1367 |
|
Participants in the aips2-tools exploder generally agreed that universal read access should be allowed to all parts of aips++ , and that write access should be arbitrated by some form of code management system. Although there was some disagreement as to what this should consist of, the majority view seemed to favour the Concurrent Versions System (CVS), a successor of the unix Revision Control System (RCS) on which it is built. At this time, however, purchase of the TeamNet software management system is being considered, for which consent will be required from consortium members. The remainder of this section and aspects of the next (Distribution) discusses the use of CVS as a fall-back option in case TeamNet is not adopted.
CVS has the advantage that it is freely available in the public domain, although it is unclear if it has yet been implemented successfully on anything other than SUN systems. CVS is optimized for tracking new releases of source code while maintaining local modifications to earlier releases. This should help to encourage the aips++ user community to implement their own bug-fixes and enhancements, and develop completely new applications independently of the aips++ consortium. This is in line with a sentiment expressed in the tools exploder that code development at remote sites should be supported.
CVS encourages concurrent development of code. Code cannot be locked for exclusive access, and in the situation where more than one programmer simultaneously modifies a file, it is left to the programmer who checks the code in last to reconcile any conflicting changes. This is at variance with our current experience with code management systems, and is currently contentious. In my opinion, CVS aggravates the problem by encouraging entire subdirectory trees to be checked out in one go, and by not providing a mechanism to determine who else has checked out a copy of a module. Checkout on a file-by-file basis is possible by making each of them a separate module, but at the expense of manually maintaining a database with an entry for each individual file. On the other hand, it should be possible to automate this. However, CVS modules must have unique names. Since aips++ will have a code search-path mechanism for the Q- and Z-routines, a distinction would need to be made between such files if they are implemented as separate modules.
As an alternative to a completely concurrent system we might consider allowing exclusive use of an individual file for a limited period of time (say one week) and thereafter allow concurrent checkout. This would require hacking of the CVS source code itself.
Once the members of the development team separate and return to their home institutions, they will need network access to Charlottesville in order to check out code, retrieve it, and later replace it. At the moment, ATNF, BIMA, NRAL, NRAO, and DIT (the institution providing CIC) are well connected to the internet. DRAO, and NFRA plan connections to the internet within the next few months. Failing that, each of these sites currently has modem access to a site which is already on the internet. In the medium term, TIFR will only have access via modem to an internet site. However, this should be adequate for logging into Charlottesville, checking out code, and mailing it to themselves. Code distribution for TIFR will however need to be a little more sophisticated and is described below.