SVN directory strucure

The AO svn repository is organized with the following directory structure:


Development guidelines

The trunk is used for development and is kept more or less "working", that is, each developer takes care of committing only when the code is reasonably tested. To assist in keeping the trunk in good state, some automated checking can be implemented, e.g. night-time compiling with emails detailing the problems encountered, automatic unit tests when present, etc.

Normal day-to-day development is committed into the trunk. Major features that require a long time to develop and would leave the trunk not working or experimental development for features that not necessarily will end up in the production code are done using separate branches that can then be merged into the trunk and deleted when the merge is complete (deleted branch versions will still be readable but just not shown as active). There is no standard naming scheme for development branches, as they are intended to be temporary.

Deployment at telescope

Only versions marked as "releases" are allowed to be run at the telescope. The full procedure is described in a dedicated page

Short-term roadmap

The software currently running at the telescope is a mix of different svn versions and uncommitted code. To get back to a working state, the following roadmap is used:

  1. copy the current working directories on adsecdx and wfsdx creating two "releases", using the svn copy command. This will create two releases that are know to work correctly at the telescope.
  2. The two releases include currently-uncommited code. Port all such new code to the trunk
  3. start normal developing.
  4. The current trunk has already some new major features (the new adsec arbitrator), plus some development branch that is close to be ready (the new aoarbitrator), so a release branch could be started in a short time.

SW distribution to third parties

The AO software will need shortly to interact with other instruments like ARGOS, LBTI and LINC-NIRVANA. The AOS is already in a similar situation. There are two kinds of interaction with these systems:

  1. Partial or total re-use of some components, e.g. MirrorCtrl and MasterDiagnostic. It is assumed that these projects will either use these components as they are found in the AO source tree, or will fork them for their own development. In either case, there is no need to make special arrangements.
  2. Communication library to send commands to Arbitrators, updating or rewriting the AOArbitrator, etc.
The second case needs to be taken care of, because a change in a communication library will break the link between the AO software and the external system.
As a minimum, the list of library files that are involved in this communication must be clearly identified. The obvious parts are the base library (msglib and the rest) plus the arbitrator library, but there may be additional dependencies and less-than-obvious interfaces (for example, the MasterDiagnostic data stream from the secondary mirror). A script can be setup to generate a package intended for use by third parties.

Two strategies were discussed to keep the various software partners aligned:

  1. Proceed with releases as described in the previous section. When a new release is nearing completion, check whether any of the communication interface libraries has been changed. If so, inform ARGOS and the others that they need to update their libraries and test them. Provide them with the new package. Coordinate the release installation with the other systems.
  2. Separate the communication library into its own module, which will be developed separately and have its own releases. Reformat our current software to link to this library. Ensure that when a release is installed, the other systems are using the same communication library version. Coordinate as before.
It is not clear whether the benefits of the second approach outweight the additional complexity. For now we stay on option #1, which requires no change in the AO code and only requires generating the library package as an additional target in the Makefile.


Some additional features that would be nice to have:

An installation log to know which release was used at a certain point in the past. This would include a log from the utility to know which of the several different installations present where used.

Separate releases between AdSec and WFS. The current source tree is "unified", but this means that a major reworking of (for example) the WFS software could possibly generate a new release without any change in the AdSec, or vice-versa. So for a single subsystem there could be multiple functionally-identical releases. Separating the two, so that each release is clearly identified with functionality changes, requires separating out the common parts used by both subsystems (MirrorCtrl, MasterDiagnostic, HouseKeeper, etc) and making three different repositories: adsec, wfs and common. It is not clear whether all these changes are worth the trouble.

Tips and recommendations on using svn

  • update and keep in sync local copy often ( svn update if working on the trunk or svn merge if working on a branch)
  • check changes status and commit often ( svn status)
  • .ssh/authorized_key file in obelix can be created in order to avoid writing the password all the time


  • Copy operational copy on telescope to the releases:
    (NOTE: Please state in the message the date since the version is operational and the original version from the repository)
    svn copy -m "[message]" [telescope working copy] svn+ssh://[username][date][system]
  • Merge changes done at the telescope (saved into a release) to current local working copy:
    (NOTE: 'version at telescope' is the original version of the file that was modified, i.e. the checked out trunk or the last file update version at the telescope)
    svn merge svn+ssh://[username][file]@[version at telecope] svn+ssh://[username][date][system]/[file]
Topic revision: r9 - 21 May 2014, AoAdmin
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback