Software Configuration Management
Software configuration management is fundamental to top-flight process
SCM In a Small Shop?
At first glance, it seems SCM is a big shop toy. Why bother with versions, releases, branches, and the like, if there are only four developers on your team? Doesn't that bring more overhead than benefits? The answers are: "yes," "you need it," and "no, it doesn't." Even small size teams can produce really good software if you can count on the right professionals, use the right development technologies, and organize your efforts correctly.
The main difference from a SCM point of view between a four-developer and 100-developer group is that the smaller group produces less code in the same time. But the quality must be the same, and the efforts have to be even better handled, because the resources are scarce.
In a small shop you can't afford losing some code because it was "unexpectedly overwritten"--your team has better things to do than rewriting it.
Making It Work
Before putting the SCM tool to work, I tried to order the source tree, coming up with something like Figure 1.
Project's directory structure.
What was placed under SCM was already in the source tree--lots of directories with tons of files like .pas and .dfm together with some .dpr. I modified each project so that their binaries would be placed under the bin subdirectory, and the .dcu would be located in obj, so that we were able to keep the tree structure clean of intermediary files.
Our product had been under development for a long time, evolving through versions 1 to 3, so at outset we used Delphi 1. By the time I joined the company, we were compiling with Delphi 5. Since many of the .dfm files were in binary format, I decided it would be a good idea to convert them all to text format so that the SCM tool can keep track the differences correctly.
Next I tried was detecting all the dependencies that the projects had on third-party installed components, even in-house ones. I wanted the source tree to be as independent as possible from installation issues, so moving the whole src tree (and I was thinking on workspaces) wouldn't be a concern. So I placed all the .dcu from the different components (each group on its own subdirectory) under lib, and updated the projects directory configurations so they used these .dcu to compile.
In doing so, I implemented the following policy: The bpl would be copied to a bpl subdirectory under Delphi installation directory, and installed in the IDE from there (the same for every developer in whatever machine they are). The .dcu files were not an issue anymore, because they were located using relative paths. This approach not only introduced a way to handle compilation, it also provided a way to deal with external elements: Whatever can be precompiled will be used in its binary form. We ended up with a tree like Figure 2.
Figure 2: The project and component VOBs.
Alas I forgot (and still regret) to reformat the code. Before creating the repository on a SCM tool, you are handling the prehistory of your system. Whatever happened there remains obscure. Once it is under source-code control, every change is controlled. Minimizing changes is good to keep a consistent view of modifications. I you need to fix a bug which involves modifying one line but you reformat the whole file, it won't be clear what you needed to change afterwards. This will be quite confusing. Unfortunately the same happens with a controlled reformatting, the code is better, but it is almost impossible to trace back changes easily. Consequently, reformat the code before or make the reformat just after the initial code import into the SCM tool.