Concurrent Versions System

CVS is a VersionControl software system, often used in OpenSource products, which allows several developers to work on the same code at the same time.

Code is managed as Modules, which are made up of one or more files and are generally checked in and out together.

Concurrent changes that do not 'conflict', or touch the same lines of a file in different ways, are merged automatically. Changes that do conflict are noted in the working files and kicked back to the user for resolution.

If you use CVS on the command line, try the CvsTools

You can get the latest version, documentation, and related information about CVS from http://www.cvshome.org, http://www.cyclic.com or http://www.loria.fr/~molli/cvs-index.html (according to the man page for the version shipping with FreeBsd 3.0).

The reason this is relevant to ContinuousIntegration is that CVS uses a similar model and its documentation has some relevant points.

CVS has no notion of "locking" a file for changes. If you want to start editing a file, you simply start editing it. There is an optional edit-notification mechanism that I use that tells you when someone else is trying to edit the same file. The mechanism does not prevent you from editing, but it does give you the opportunity to find out who else is editing and talk with them so you can all figure out whether you are stepping on each others' toes.

CVS does have the concept of locking, although it is not the default. The manual states: "Currently the usual way to get reserved checkouts with CVS is the cvs admin -l command (see admin options)."

CVS requires that you merge in the source branch you are working on before you can commit. This is important because it makes the individual user, and not the mysterious CVS server (quite likely on another machine), responsible for sorting out any conflicts between what you are about to commit and what others have committed. This encourages the practice of CommitEarlyAndOften to reduce the chances of having to merge.

Anyhow, the part of the documentation relevant to ContinuousIntegration is in the section titled "What is CVS Not?" The important point for our conversation are (copied from http://www.loria.fr/~molli/cvs/doc/cvs_1.html#SEC3):

CVS is not a substitute for management.
Your managers and project leaders are expected to talk to you frequently enough to make certain you are aware of schedules, merge points, branch names and release dates. If they don't, CVS can't help. CVS is an instrument for making sources dance to your tune. But you are the piper and the composer. No instrument plays itself or writes its own music.
CVS is not a substitute for developer communication.
When faced with conflicts within a single file, most developers manage to resolve them without too much effort. But a more general definition of "conflict" includes problems too difficult to solve without communication between developers. CVS cannot determine when simultaneous changes within a single file, or across a whole collection of files, will logically conflict with one another. Its concept of a conflict is purely textual, arising when two changes to the same base file are near enough to spook the merge (i.e. diff3) command. CVS does not claim to help at all in figuring out non-textual or distributed conflicts in program logic. For example: Say you change the arguments to function X defined in file `A'. At the same time, someone edits file `B', adding new calls to function X using the old arguments. You are outside the realm of CVS's competence. Acquire the habit of reading specs and talking to your peers.
CVS is not an automated testing program
It should be possible to enforce mandatory use of a testsuite using the commitinfo file. I haven't heard a lot about projects trying to do that or whether there are subtle gotchas, however.
CVS does not have a built-in process model
Some systems provide ways to ensure that changes or releases go through various steps, with various approvals as needed. Generally, one can accomplish this with CVS but it might be a little more work. In some cases you'll want to use the `commitinfo', `loginfo', `rcsinfo', or `verifymsg' files, to require that certain steps be performed before cvs will allow a checkin.

You might also look at http://www.loria.fr/~molli/cvs/doc/cvs_10.html#SEC89, "Choosing between reserved or unreserved checkouts."

I find that VisualSourceSafe's default behaviour of "checking out" files (CVS's locking) is very useful. I'd like to know who else is working on files I'm interested in. Is there any CVS client for Windows that can do this as cleanly as VSS?

No, no, no! CVS does not lock files! That's the whole point (C = Concurrent). Instead, CVS requires that a user have a derivative of the latest version in the repository before committing changes. -- TaralDragon

CVS does not lock files by default. You can configure it so it does. This mode of locking is analogous to VSS' "check out", just as VSS "shared check out" is analogous to CVS checkout/update. -- RobertWatkins

But if you just want to know who else is working on files, you can put a watch on those files (http://www.cvshome.org/docs/manual/cvs-1.12.1/cvs_10.html#SEC83). -- SarahElkins

How does CVS deal with 'binary' documents? I'm dealing with a project that uses VB and another software development language. VB keeps most things in text files, so there isn't much problem using a tool like VSS, but the other development language stores code modules as binary files and this messes up VSS, so that only one person can work on the code in a module at a time. For unrelated reasons, it's difficult to have many code modules to reduce the chance of change collision. Does CVS provide any help in this situation?

CVS can store binary documents. However, it makes no attempts to compare between them. Because of this, it can not perform merges, which means that the user has to deal with any conflicts manually. From the sounds of it, I don't think CVS would help you here. Can you possibly survive without that file in your repository? -- RobertWatkins

You wouldn't be able to get the full range of benefit with binary files in CVS, but it might still have some use. If nothing else, it would help you archive what the file was at every stage. Not as good as the fine-grained diff/merge/etc functionality you get with plain text source code, but better than no VersionControl whatsoever. I've heard it suggested that the content-side of a web company could also use CVS to store its graphics files, too, what with disk space being cheaper than graphic designer man-hours. Haven't worked in a place that does that, though.

I'm working on a large web application with images stored in CVS along with source code and static documents. Since images are never edited, only perhaps replaced en masse when graphics designers deliver them, there is no need for conflict handling. Most projects don't need to worry about intensive editing of binary files, and those that do need a diff/patch mechanism that understands specific binary formats; expecting it from a general purpose tool like CVS is unreasonable. -- LorenzoGatti

Those in the know say that VSS locking is necessary because the diff/merge conflict resolution is very sub-optimal and shouldn't be relied upon. Experience shows that conflict resolution in CVS is accurate and conservative (it will abort the checkin and require the user to manually resolve the conflicts). In practice, if two developers on a project are making conflicting changes to the same file, there's a bigger problem than any source code control system can resolve. -- StevenNewton

CVS is an excellent tool, but it has some annoying problems. I don't know if they are accidental or intrinsic. In particular, it's hard to do refactorings at the file level in CVS, i.e. things like

So you often end up having to lose history in order to adjust the structure of your project, as it grows and you discover more how things ought to be structured.

Or are there natural solutions to these problems that I've never discovered?

Don't rename a file in the repository - avoid any direct access to the repository. 'cvs add' it under the new name/location, with a comment about the old name on checkin. Then 'cvs remove' the old file. This preserves history, in a slightly disjoint fashion. Old snapshots will recreate OK.

That would be how Eclipse IDE handles a CVS class rename.

See: CvsTools for a "cvsmv" script

CVS has pathetically poor merging functionality when merging branches to/from the main tree. What products out there offer better merging functionality?

Could you list some specific deficiencies?

SubVersion is a project to rewrite CVS from scratch, in a more flexible and extendible way - and then to extend it. Currently (March 2003) it's usable, and already provides:

It may be missing some features you depend on in CVS, but if you're doing plain-vanilla CVS, you may be able to switch over now.

MetaCvs is a client-side extension to CVS: it uses the CVS server to store version history in a slightly different way. This means you can't access the same project with MetaCvs and a regular CVS client, but you probably wouldn't want to anyway. MetaCvs gives you:

Simple branching and merging means this: you type "mcvs merge foo" to merge the latest crop of changes from branch foo to wherever you are. The merge from there to here is remembered. Also "mcvs branch foo" creates a branch, "mcvs sw foo" switches to it, and "mcvs lb" lists the branches.

CVS is the key ingredient in a DevelopmentServer.

From QuestionsForNewProjects:

I for one despise CVS. There also was recent news that LinusTorvalds' productivity has gone up 10 fold since switching to BitKeeper. Linus liked it so much, he rewrote it as FreeSoftware (GitVersionControl).

If I recall correctly Linus didn't use CVS.

A quote from the web: "Linus say that he used CVS at work and wouldn't even consider using it unless he got paid for it. So, in Linus opinion using it was worse than having no version system." I agree with that sentiment.

Quick question: with 42 pages (as of 10-16-05) should this have it's own subcategory such as CategoryCvs?? Delete this if it's not needed. I suggested it because I had no idea what CVS is not having time to contribute to OpenSource programming in a couple of years. WyattMatthews

CVS (and SVN) are really not used anymore for new projects. MercurialVersionControl and GitVersionControl are the two popular systems now.

See also CvsTutorial, WinCvs, CvsNt, AntHill (Build Management Server), SubVersion, CvsBook, CvsOnRedHat, CvsTools, CvsToys, CvsWeb, CvsWebClient, CyclicCvs, MetaCvs, RefactoringWithCvs, TortoiseCvs, ViewCvs, CvsGrab

CategoryConfigurationManagement CategorySoftwareTool

EditText of this page (last edited April 14, 2014) or FindPage with title or text search