Uwe Ohse

articles

Where CVS failes


This text lists a number of shortcomings in CVS.
No changesets
There is not way to cannot commit changes to a number of files atomically: If the commit to one file fails the other files will be accepted, which might have devasting effects of the changes depend on each other (.c, .h?).
No file move
There's no clean way to rename or move a file. (the only ways i see are to either lose VC history and tag, or manually adjust the state in $CVSROOT).
No distributed repositories.
CVS has a strict "one server" model:
Access control is lacking
CVS basically hasn't a notion of access control. It leaves this task to the operating system (which isn't necessarily a bad thing, but CVS hasn't been written with security and access control in mind).
While there are a number of workarounds these still offer no real protection against malicious users.
CVS is slow
Period.
No version control for metadata
Ever checked out a file from CVS and saw that the access rights are wrong?
Branches are done wrong
CVS branches are based on tags in each file, and are basically implemented by abusing version numbers. This means:
No check sums
CVS is based on RCS, and RCS didn't use checksums on files. Things get funny if you detect that your repository has had a bad disk sector some months ago (SCSI disks should be forbidden to remap bad sectors, but that's a different story). With many other VC systems you can do an integrity check on your repository, with CVS you can only hope that something which is needed for a build is broken (instead of, for example, documentation).
CVS add / remove access the repository
commit should do that.
Directory support is lacking
Did you ever try to move a directory? A tedious task.