Providing customized source code control with CVS
Providing customized source code control with CVS
Summary: You need source code control, and CVS is very good at that. It has been found to be very reliable in extensive use,
Let's look at the source code control system criteria as described in my source code control paper:
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.Using these criteria, CVS is an excellent choice for many programming shops.
CVS is generally easy to use. One more interface, or a few commands to learn. There are tricky parts, but these can be encapsulated into Perl scripts or the like, making things easier. CVS can operate on multiple files at the same time, unlike some older SCM systems, and it is convenient to use on entire projects. While CVS is complete and usable by itself, its client-server orientation means that there are various different client applications to suit different shops or developers. Depending on what the users are doing, they might find their jobs made easier by CVS. CVS offers an excellent system to make and test large changes without interfering with regular development, and can show the user what changed when.
CVS is not designed for any particular development process. It does have flexibility built in to work with most processes. There are "hooks" in it to permit calling various programs at certain points, and it is possible to write wrappers that will issue CVS commands while handling whatever else the process needs.
CVS is generally inexpensive to install and use. The cost of installing the software is the people and machine time needed to get it running and properly configured, which is usually not great. An experienced person can usually accomplish this, along with other related tasks, in a week or so. Its hardware requirements are modest, and an inexpensive server can serve dozens of users. While the administrator or administrators do need knowledge of the software and its operation, the actual time spent on such things is typically small, perhaps two hours a week or less for a system supporting dozens of users.
CVS runs about as reliably as the server. In my experience, it will slow down under heavy load, but as long as the system configuration is good it will not stop. It is also very good about not corrupting the repository, provided again it is set up right. Developers hate losing changes they have made, and if they find the system in place is faulty they will use their own informal systems, which creates inefficiency. With CVS, this is not normally a problem.
This means that CVS is a very good system, provided that it does what you need it to do. Let's look at that in more detail.
CVS was originally designed by Prisma to work on the Sun operating system kernel, involving more than ten thousand files comprising millions of lines of code, being worked on by fourteen developers. It gave each developer his or her own work area ("sandbox" in common usage), and allowed Prisma to keep track of new versions of the Sun kernel. It has since been used in distributed development of large software projects, with great success.
The success of CVS in such environments is due in part to its support of automatic merging of changes. This has several very useful results:
The most controversial of these features is concurrent development, allowing several developers to work on the same file simultaneously. This frightens many people who have no experience with it, but in practice it works very well, and developers who approach it with trepidation frequently come to love it. CVS also has features to keep track of who is working on a given file, for situations where this really is inappropriate, or for shops that do not wish to practice concurrent development.
The automatic merging allows CVS to maintain branches, which are lines of code development that are nominally independent but which allow the merging of changes. One type of branch is the feature branch, where developers will make major changes to the software without interfering with the usual run of maintenance. Another type is the release branch, where the developers can mark a release and maintain it while getting more work done for features for the next release.
Not everybody needs to support local changes to code from somewhere else, but CVS fully supports that for those who do need it. CVS creates a vendor branch, which tracks the versions that come in, and merges in local changes.
CVS maintains files in the generally efficient RCS format, in which the latest version is instantly available, and all changes are recorded along with log comments.
CVS works very well in distributed environments, with developers all over the world. By allowing each developer his or her own local workspace, it allows developers to be efficient with intermittent Internet access. Such Internet access can be sent through VPNs, or CVS can be set to use the ssh protocol for high security on insecure communication lines.
That being said, CVS is not perfect, and may not be the correct choice for everybody. CVS was designed to work with large numbers of text files that can be meaningfully merged, allowing each developer his or her own workspace. The most serious limitation is if it is not possible to allow each developer a separate workspace, for example if the workspace needs to access a web server or database. In this case, it is necessary to set up virtual workspaces, copying each developer's workspace into the test workspace as necessary, or to use another source control system. CVS does not keep track of changes in directory structure, and tracks movement of files somewhat awkwardly. CVS was not optimized to manage binary or non-mergeable files, and so does not provide its usual benefits for those. If your shop moves files around frequently, or has few text and many binary files, you may find another system better suited.
However, for most software shops, these are not serious issues, or can be worked around, and so CVS is usually a very good choice.
All contents of these pages Copyright 2002 by David H. Thornley.
Permission granted for verbatim copying and use within an organization.