A History of Code Management at D0

• D0 Code Management during RunI
• Why did the system need to change and why did it turn out the way it did?
• How was the new system designed?

The Run I D0library

describes the Run I D0library, it's organization, strengths and weaknesses.

D0 Code Management

describes the Run I code management system we used.

D0 Release Procedures

describes the Run I code release procedures.

• The major impetus in the redesign was the requirement that all Fermilab experiments move from primary reliance on DEC VMS machines to a more egalitarian system. This implies, for the time being at least, to UNIX, in all it's flavors. In addition we needed to support NT and other such operating systems in the future.
• A major consideration in the design was the desire of both experiments to move from an almost purely Fortran coding environment to primarily C and C++.
• Both experiments are going through a rapid code development period so code must be able to be released quickly, but must still have good control over the versions of each package (library) used to create a particular executable.
• No one has a lot of time to write a completely new system.

For a number of reasons found in other sections on this site, cvs, the Concurrent Versioning System was chosen as the code repository, cpp was chosen as the code preprocessor for all languages and UPS/UPD the Unix Package System and Unix Package Distribution developed here at Fermilab were adopted as the version setup and distribution mechanisms respectively. All of these products are in the public domain and work well. Also, for most users the details of what they do and how they do it are unimportant. Developers have to know a few cvs commands and how to write "#include"s and "#ifdef"s for cpp. Everyone needs to know how to "setup <product> [<version>]". These have very short learning curves.

However, the second and third points above force major changes in not only how the code is released, but in how often it's released and what people have to know and do if they want to deviate at all from the "standard" versions of packages. Those requirements, especially the second, the move to C++ present some really tough problems.

The main problem arises because of the use of header (include) files in C and especially C++. In Fortran it is easily possible to change an include file in such a way that previously compiled modules don't need to be recompiled to run correctly. This is not for C++ headers. There are, apparently no changes that can be made to a C++ header that won't cause some compilers on some operating systems to create code which crashes or gives incorrect results. The reason for this is that in Fortran, most decisions, such as how much space needs to be allocated to store an array, is made at compile time. So once the code is compiled, that decision can't be changed. In C++, many of these decisions are made at run time.

What this means is that all code that depends on a given header file must be recompiled any time that header file changes. In addition, there must be a way for the system to guarantee that all object code archives (.a files) used in a given link were all compiled using the same header files. These problems were solved elegantly (but not necessarily "easily" (for the developer and user)) by adopting the SoftRelTools package developed by the BaBar experiment at SLAC.