The Hobby Eberly Telescope (Het) has chosen Subversion [link me] as the version control system for source code. Subversion will manage and do version control on your directory structure as well as files within your directories. Even for single programmer projects a version control system is useful. It will allow you to keep and examine the history of a file over time as well as the history of the entire project. In addition you can recover older files to see a procedure that you had once implemented, later abandoned, and then found that you needed again. You can revert to a previous version of a file in the event you are making extensive changes and come up on a dead end in your development.

With Subversion a master copy of your software is kept in a repository on a specific machine while you make your changes in a working copy on your local machine. When you have created and tested a change you then check in your changes to the repository. In a multi-programmer project the other programmers can then check out your changes. Subversion uses a copy-modify-merge model to to do the version control rather than a lock-modify-unlock model that may be more familiar to programmers. This allows more than one programmer to work on the same file at the same time. If there are any conflicts between the changes from the two programmers, these conflicts must be resolved before a final change can be checked into the repository.

There are currently two repositories in use at Het. One is located in Austin on the machine hetdex-pr.as.utexas.edu and one is located on the private network at the Het in west Texas on the machine ute2.as.utexas.edu. hetdex-pr is primarily used for the Tcs and Camera software for the Wide Field Upgrade while ute2 is primarily used for local projects at the Het. These two repositories will be merged in the near future. Both machines use the svn plus ssh protocol for talking over the network so a repository name looks something like ​svn+ssh://<user>@<host>.as.utexas.edu/<project>. All local users have an account on ute2.as.utexas.edu and I will add local users to hetdex-pr.as.utexas.edu.

This page describes the software development procedures in place for the development of the Tcs and Camra control systems.

This section last updated 2016-11-08

1. Development occurs in svn trunk.

2. Larger or more complex feature changes requiring intermediate commits that are (partly) non-funcitonal or developments over longer periods of time (spanning a significant fraction of a deployment cycle) should occur in a branch. This branch should be frequently merged from trunk to ensure that it picks up changes by others. It gets merged back to trunk once the features are considered stable.

3. We periodically branch from trunk into a deployment branch. This is what is run at the HET for ops. We expect to branch monthly for the time being to be in synch with the dark-time science and bright time engineering cycle.

4. Only bugfixes and configuration changes are allowed in the deployment branch. In exceptional cases we will deploy small new features if proven safe and warranted by the science ops or engineering needs. All such changes have to be discussed and agreed upon on hetdex-tcs and het-operations prior to deployment.

5. During engineering time, we will be running trunk at night for testing during the first week of engineering, then branch, and run the branch for ~1 week to stabilize it for the coming science run.

6. All developers are responsible for keeping the integration test script (orchestrate-trajectory) up to date and functional at all times.

7. Prior to any commit to trunk or any branch, we will execute orchestrate-trajectory, running at least all affected subsystems, to ensure that (a) the script still works, (b) configuration is up to data with the changes, (c) basic system integration and integrity is not affected. This test does not preclude the usual thorough testing before committing but augments it with basic integration testing.

8. We update the orchestrate-trajectory framework and the associated subsystem simulators to include future systems interfaces and functionality. The absence of simulation capability is not a valid excuse for not testing changes with orchestrate-trajectory. Rather that capability should be added to the simulation packages.