Hcal Repositories and Builds at FLC
The central CALICE code authority is a CVS repository hosted bey DESY Zeuthen. We keep semi-private daughter repository in the FLC AFS space to channel Hcal code developments before release to the official repository. In addition, three different builds of these repositories are provided. Thus only people developing central code have to check out and compile the reconstruction software, while people doing analysis can run from the central builds.
NM 2008-06-20: The following does not exactly describe the current status, but rather the plans for clean-ups comming up the following days.
Three different builds of all CALICE code are provided:
- stable - corresponding to the latest tagged version of the CVS repository
- pro - corresponding to the current HEAD of the CVS repository
- pro_test - corresponding to the CVS HEAD plus internally released developments
For each package of the CALICE code, one git repository is available with following structure:
- A master branch 'master', which is kept in sync with the CALICE CVS on a daily basis (cron-jobs), so the tip of the master branch is identical to the HEAD of CVS with a maximum latency of 24h. The latest CVS tag, so the basis of the 'stable' build, is a well defined point of this branch, while the 'pro' build is automatically compiled from the branch's tip every day.
- A development branch 'devel', which is automatically rebased to the 'master' branch and contains additional commits of Hcal developments. The 'pro_test' build is automatically compiled from this branch's tip every day.
Code migration policies
The default path of newly developed code (including major upgrades and changes) is
- private development repository
- devel branch of the FLC repository
- master branch of the FLC repository
- Official CVS repository
Migration from 1. to 2. is done on request of the developer. Step 2. to 3. requires tests and discussions inside the Hcal group. Step 3. to 4. happens automatically. The FLC repository is not writable for everybody, so steps 2. and 3. need coordination with the maintainer (currently Angela).
For simple and urgent changes (e.g. bug fixes), step 2. can be omitted - everybody is encouraged to act responsible here!