| All the source code control (SCC) software that I have seen has some kind of labeling function to track either checked-in binaries or source code. (Remember that I am not for checking in binaries, but I mention this for the groups or teams that do. See Chapter 2.) This type of versioning (or more appropriately named labeling) is typically used to track a group of sources that correspond to a product release. Most of the time, they combine labeling of the sources with the branching of the source code lines. I like to stick to the recommended practice of branching as infrequently as possible. Some companies and groups at Microsoft branch code off the main source line after every build and use the build number as the label. Their source tree usually ends up being an administration nightmare because some critical files get buried so deep that they forget they are there, and their SCC tool does not have a good way of managing them and bringing them back to the surface or top level of the tree. Regardless of the SCC tool you use, keep your labeling simple, and use the build number that the sources or files were built with. As mentioned in Chapter 2, if you would like a deeper look at SCC tools, I highly recommend Software Configuration Management Patterns by Berczuk and Appleton. The detail on source control that is covered in that book is unmatched. Microsoft Sidenote: "I've Been Slimed" In the early 1990s, in the Windows and small business server group, we used a primitive source code control tool called Source Library Manager (SLM, affectionately pronounced slime). The labeling function was so unreliable that we would not even bother to label the sources after each build. So how did the developers, testers, and build team look up previous check-ins to previous builds? Well, fortunately, the projects were not as complicated or as large back then as they are today, so this was all manageable through our release and build process. As mentioned in Chapter 1, "Defining a Build," we kept about two weeks' worth of all the sources and binaries of each build on a release server. This allowed the developers, testers, and builders quick access to the previous builds without having to rely on the labeling function of the SCC tool. If someone needed files from a build that were not on our release server, we had custom tools that would scan the sources on the source trees by date and version stamp and copy the sources to a share. Then we would rebuild those sources on that share. Because we had weekly tape backups of the release servers, we could always restore past shares on the rare occasion that we had a reason to do this. Bringing this forward to 2005, Microsoft uses a powerful, internally developed SCC tool that handles labeling and branching extremely well. This was probably the most compelling reason to move to the new tool years ago. If you want to adopt this tool, look at the SCC tool in the Visual Studio Team System. It has all the features of Microsoft's in-house tool and more. In the future, there are plans to replace this in-house tool with the Team Foundation Source Control (TFSC) tool mentioned in Chapter 2. |
|
