Thornleyware logo

Providing customized source code control with CVS

Source Code Control White Paper

Your shop undoubtedly has a large amount of source code, built up over the years in a more or less organized fashion. This may be for sale, or (more likely) for internal use. It represents a lot of work, and hence a lot of expense. It serves many needs, and is the result of a great deal of analysis and design. You have responded to the needs of your customers, whether these customers are internal or external, and many of their complaints have been fixed. Your code base is valuable, since it represents so much work and is useful for the customers.

The most primitive way is to back up the system regularly, which means you can at least retrieve the latest version. This leaves a lot of potential questions and difficulties.

A good SCM system will address all of these, and more.

There have been a great many systems designed for this purpose, that serve with various degrees of success. Any one of them will help by keeping track of your code, allowing you to reproduce previous versions, and logging any changes made.

When selecting a source code control system, you need to consider several things. You want it to be seen as a tool by your developers, not as a hindrance or a source of annoyance. You want it to fit in to your preferred development process and not interfere with it. You want it to be inexpensive to install and use, counting all costs. You want it to be reliable, and not lose information. Most of all, you want it to do the things you need it to do. For these criteria, CVS is an excellent choice for many development shops.

There are other things to consider.

What sort of network performance do you need? If you want to have developers working at home, or at multiple sites, you want to allow them access, without jeopardizing security. If developers may not be always connected, you want them to be productive anyway.

What sorts of platforms do you have? You may have a mixture, perhaps some Microsoft Windows and a few different versions of Unix, or even some Macintoshes. Whatever you choose needs to run on all the platforms your people will work on.

Do you need to support multiple releases, or one at a time, or do you just deploy immediately onto production systems? In the latter case, you don't need any sort of release handling.

How many people and how much code do you have? The solution you choose has to work on the scale you need.

Do you have software from elsewhere, and need to maintain local changes through version changes and upgrades?

All contents of these pages Copyright 2002 by David H. Thornley.
Permission granted for verbatim copying and use within an organization.


Contact: webmaster@thornleyware.com