Source Control Management


Features to check

(from Slashdot) Version control system minimum requirements by Anonymous Coward

IMHO, these are the bare minumum requirements:

  1. atomic commits - your change happens only if all the files can be processed.  This prevents a corrupted workspace when CVS processes half your files in a commit and then exits on an error throwing the other half of your files on the floor.
  2. change list management - all commits have a unique reference number.  CVS process files by directory instead of by workspace, so it is impossible to tell which files are associated with a commit.
  3. access control by workspace or workspace directory - the ability to give certain users or groups access to certain workspaces or directories.  Ideally, access control can be by done by bug id.
  4. graphical resolve of conflicts - a graphical three-way diff is the only way to resolve complex conflicts
  5. The ability to move files and directories and maintain file history and label integrity from the client.  CVS requires the whole workspace to be locked so that  moves can be performed on the server side and does not maintain label integrity.
  6. web viewer and graphical difference viewer - the ability to browse via the web change set lists to see what files changed and what the actual differences were.
  7. the ability to integrate workspaces across projects - the ability to arbitrarily merge/integrate any source code from any project to any other project.
  8. powerful labeling features (parallel development and prior version support).
  9. rollback or undo multiple changes - this is great way to recover from a developer commit disaster.
  10. multi platform support - must run on all platforms.
  11. command line and graphical interface.  Command line for scripts and graphical interface for those who can't work without it.
  12. push and pull notifications - built in support for e-mail and news group notification of changes in the workspace.                

(from Slashdot) 10 problems with CVS by  j1mmy (

  1. Documentation is piss-poor. There's an easy solution to that one, but nobody likes writing documentation.
  2. Updates don't always work as expected. They won't grab new directories and a few other quirky things.
  3. Empty directories should be pruned by default in a checkout or update.
  4. I'm tired of seeing a CVS directory everywhere I look. How about .CVS instead?
  5. Access control is poorly handled. It's good that you can map virtual user names, but it would also be useful to control access by groups.
  6. Local CVS tree file ownership is by user, not the CVS owner. This opens up all manner of problems for users with a local CVS repository. Repository data should be in a non-user account, checkout should force authentication, and the server should handle who has access to what. This would not be tremendously hard to manage, since in the general case a user has access to a project or not. Fine-grained access control of the repository isn't a common necessity.
  7. Plays badly with (most) IDEs. When I want to work on a project in an IDE, it floods my checked out directories with all manner of crap I don't want in the repository. You can set up refuse files to clean these out, but it might break your IDE project. This is more a fault of IDEs than CVS, really.
  8. Needs smarter add functionality. I don't like writing stuff like 'find ./src/ -name "*.java" | xargs -n 100 | cvs add' just to hunt bring in my new source code.
  9. CVS is a boring acronym.
  10. I can't think of a tenth thing.

(from Joel on Software) CVS vs Perforce vs ? by Rajesh Jayaraman - Friday, September 27, 2002

I have personally used both CVS and Perforce extensively. And when I moved from CVS to Perforce, it definitely was an "upgrade". A few of the really good reasons why the 750 bucks is worth it

a. A commit is a transaction - How many times have you started a long checkin on CVS, and the network or something goes down, and you have code breaking. In P4, an entire commit(submit) is an atomic operation. This is a real blessing, because you can be sure that a checkin will never break the code (Provided you have verified it doesn't before checking in!!!)

b. P4 is not as chatty as CVS - P4 maintains state on the server, which means you do not have those dirty /CVS directories in your code. What CVS does in order to do an update is, it communicates to the server(repository), which version of the file it has. Then the server figures which file version to give it. And this is done for each directory in turn! The volume of communication is very large between the client and server.

c. P4 maintians labels as references to the file versions instead of placing a marker on the physical file itself.

d. P4 maintains differenct branches as distinct files - Unlike CVS where all branches of a file are marked on the same repository file

The above two combined, give you a much superior performance when it comes to labelling and branching. I have persoanlly faced situations where we have had to maintain a large number of branches, and releases on each of these branches.

CVS locks each file it's trying to label, and if you are labelling the whole source tree, every developer's work is pretty much frozen. In P4 labelling a whole source tree (of about 5000 files) takes 2 minutes flat.

Apart from this, pretty much everything that CVS provides is provided by P4, including watching, auditing etc.

The bottom line is this: If you are working on a really large project, with a lot of source branches go for P4. If you are working on a WAN (as we are) go for P4. If you run a single or dual branch software shop, with everyone sitting in the same place, go for the free alternative. You won't notice the difference.

(From JOS) Robert Tuesday, October 07, 2003

"what are issues with CVS that would drive people to choose another SCM, either open-source or commercial? "

Where to begin?

  1. branches are expensive, fragile, and semantically braindead.
  2. you can't rename a file without losing its history or fiddling with the repository itself, which will likely cause gremlins later on.
  3. operations are file-centric, rather than tree-centric.  It is fragile, error-prone, and generally a waste of time to attempt to mark "logical changesets" to a tree, using some kludge like CVS tags, or heuristics on check-in logs and times.
  4. since commits are not atomic per tree, it is nearly impossible to revert a "change" as a unitary operation if it crosscuts more than one file.
  5. it is not possible to follow development on a branch, versioning your own changes, without write access to that repository.
  6. You can't rename a directory without losing ALL of the history of all of the directories and files underneath it.  Or, you can hack the repository, which also has its cons, usually in the form of gremlins later on.
  7. You can't version symlinks.

The list goes on.  This is really the kind of thing that you never really realize how truly awful it is until you've had the opportunity to use something better.


Tigris Subversion






Due to differences in security mechanisms, not available for NT.


Team Coherence Version Manager


Big, difficult to configure, expensive.




MS Visual SourceSafe

Unstable, slow on WAN links (add-on available to increase performance), server not available on Unix systems.

"SourceSafe was created by One Tree software. Microsoft orginally had their own version control system, called Delta, but it was yanked from the shelves shortly after it was released. (If anyone knows the story behind this, I'd love to hear it). Microsoft quicky bought One Tree, re-packaged the existing versions, and then sold off the non-windows versions. Metrowerks picked up the Mac version, but they've dis-continued it."

SourceGear Vault





Code Co-op






"The CS-RCS/CS-CVS product family is today the most powerful, yet easy to use, version control system for Windows. The CS-CVS solution consists of two products: