Section 4.1. Why Do I Need SCM?


4.1. Why Do I Need SCM?

The source code of all projects changes over time as the projects grow. Most of the time, the people working on the project add new parts to it and fix the broken ones. Occasionally, large reorganizations of the source code can occur, sometimes as part of cleaning up the code (also known as refactoring).

The simplest and most unwise way to work on a project is for a group of people to work on the project's files in a shared directory. Each developer has to be very careful not to change any file unless he can be sure that he is the only one changing it.

Being well aware of the woefully short life span of most hard disks, if the group is wise it makes regular nightly backups off site, keeping the last three copies available locally for convenience. If an individual is going to make a large change, she can make her own copy of the affected files locally, just in case something goes horribly wrong while she's making the change. When the time comes for a release, the current versions of all the files are copied to "somewhere safe."

This simple way of working on projects is how an estimated 40% of software projects are developed.[1] I don't know about you, but that figure is hard for me to believe. Sure, it's just an average, and on average every human being has one ovary and one testicle, but if the 40% value really is true, then stunned contemplation is my first reaction. Surely all those people must have heard that there are software tools to help with this kind of thing? The Capability Maturity Model (CMM; see http://www.sei.cmu.edu/cmm) certainly has. For your project to be anything but "ad hoc, and occasionally even chaotic," it says you need SCM.

[1] Three different references that suggest this value are:

The rest of this chapter can serve as an introduction to some of the major problems that such an environment will almost inevitably get tangled up in, and some of the ways to avoid those problems. If this is the situation you are in, the next few paragraphs should also help motivate you and your group to introduce an SCM tool. In the too-simple environment described, eventually the following situations or questions will occur:

  • More than one person wants to work on the same file at the same time, but it's too hard to find everyone and to get them to agree that a file is available, so nobody works on that file. Integrating different people's work becomes very hard to schedule and takes a long time to finish.

  • "All this code used to work! What changed since yesterday?"

  • "When was this line of code changed? There's a bug in it and we need to know how many versions of the product are affected."

  • "Who changed that line?" This question usually means either "For what purpose was that change made?" or "We need to know who would write code like that!"

  • "Most of those changes were a mistake and they should be removed, but we do want to keep a few of the changes."

  • "We need to fix that bug in multiple versions of the product."

  • "Hey! Who stomped on that change I made yesterday?"

A good SCM tool can provide solutions to all of the above situations and questions. No software project of any size should be attempted without some form of SCM, and occasional copying of the source directories doesn't count as adequate SCM!




Practical Development Environments
Practical Development Environments
ISBN: 0596007965
EAN: 2147483647
Year: 2004
Pages: 150

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net