Jared's Weblog

Main Page - Blog - Books - Links - Resources - About - Contact Me

This page is based on the source code management appendix (Appendix B) in Ship It!.

(I'm experimenting with Google's Adsense advertisements. If they really annoy you, let me know. My contact info is on the "Contact Me" link at the top of the page. -Jared)

Source Code Management Tools

Source Code Management (SCM) programs (also generically known as version control systems) keep track of your code and the changes you make to it. In addition, a good SCM associates specific versions of the code with important milestones, e.g., a product release.

What’s Available:

CVS-- A free, open-source client-server SCM. Does everything you need, but the command-line interface is a bit arcane. CVS is used by companies large and small all over the world.

Subversion-- The self-avowed replacement for CVS, it does most of what CVS does, plus a lot more. Like CVS, it’s open-source and free.

MS Visual SourceSafe-- Microsoft’s SCM, it’s integrated with a lot of their development tools and IDEs. If your shop paid for Microsoft’s development tools, you’ve probably already paid for SourceSafe and have a license waiting to be used.

BitKeeper-- BitKeeper is a commercial product that the Linux kernel developers used for several years, and they have reported a significant increase in productivity as a result.

Key Concepts:

Repository

Where the source code is stored.

Workspace

Your local copy of the source code on your machine. You check code out of the repository into your workspace, work on it for awhile, and then check it back into the repository.

Client

The program you run on your machine that interfaces with the repository through the server.

Server

The program that sits in front of the repository and deals with the clients.

Branches

You branch a project so that you can have multiple development paths with that project. For example, one branch of a project would be used for bug fixes on the current version, and another branch would be used to develop the next version.

Tags

The way you identify a specific version of a file, directory, project, etc.

Merging

When two or more developers are working on the same file, the changes must be merged.

Locking

How the SCM determines who can make a change to a file. In a pessimistic locking system, only one person at a time can make changes to a file. In an optimistic system, many people can make changes, and all the changes are automatically merged when the file is checked in.

The Cost of a Tool

Many development teams prefer to use free tools, while others prefer commercial products with support contracts. We tend to favor tools that are freely available and get support from the user community, but we don’t pick tools based on the cost. We choose tools based on what works. If several tools can fill the need our teamhas, we’ll pick the free one. You’ll need to figure out what works in your environment.

How to Choose:

Features

Tags-Is it easy to tag specific versions of your source code? Is it easy to use tags to access that code?

Merging-Are your merges manual or automatic?

Multiproject projects-Can you include other projects, modules, and versions in your project? How hard is it to define interproject dependencies?

Ease of use Does the system integrate with the the editors or IDEs your team is using? Can it be embedded within your build scripts? Remember, if it’s not convenient to use, nobody will use it.

Scalability Can the system handle all your files? Projects? Users? Without losing or corrupting files?

Performance Are the basic operations fast enough to be worthwhile, or will people bypass them because they don’t want to wait?

For More Information:

See Practice 2, Manage Assets, on page 20 of Ship It!