Reasons to prefer CVS over SVN or Git [closed]

Question

I just found an open source project that still uses CVS. I wondered if there were still any reasons to prefer CVS over SVN or Git nowadays. (I don't count being too lazy to migrate as an answer! ;-) )

Does CVS have anything the other two lack? Say, support for $OS or $fancy_tool?

In “What are the advantages of using SVN over CVS?” there are elaborated answers why not to use CVS. But I want to ask the other way around. CVS can't be all bad. Or is it?

Specification

Answer 1

I still use CVS for some of my own personal stuff.

Unlike with Git, you can easily check out only a subset of the repository.

And CVS assigns sequential version numbers (1.1, 1.2, 1.3, ...) to each file. In Git, version numbers are 40-character hexadecimal checksums. In SVN, revision numbers are sequential across the entire repository; a given number applies to the entire repository.

And CVS lets you expand version numbers into each file when checking it out, making it easy to identify which version a file is without reference to the repository it came from.

So I find CVS (and sometimes even RCS) convenient when the repository is a collection of largely unrelated files, and I'm more interested in tracking changes on individual files, but revisions of the repository as a whole are not particularly meaningful.

(That's not going to be the case if the repository contains source files used to build a single program or library; in that case, you want a coherent history for the project as a whole.)

Finally, CVS stores the history for each file in a single file (with the same format used by RCS) with a relatively straightforward format. At least once, I've had to manually reconstruct a saved CVS file that had become corrupted. I'm not sure how I could have done that with SVN or Git.

UPDATE: This question has drawn a couple of unexplained downvotes. I can only guess at the reasons (and I don't worry much about the occasional downvote), but perhaps some readers think I'm advocating CVS as a better system than SVN or Git. I am not; I'm merely pointing out that CVS can have some advantages in some fairly narrow circumstances.

Retene

In the years since I wrote this, I've almost entirely abandoned CVS in favor of Git. – Retene

Answer 2

You have to understand that Subversion was written to directly replace CVS and the issues developers have with CVS. Subversion was written, so that CVS users could easily transition from CVS to Subversion since they use the same workflow and many similar concepts.

This is sort of like asking how was MS-DOS superior to Windows as an operating system. I could come up with some bogus reasons ("Well... ...uh... MS-DOS needs less memory."). But, in the end, Windows was written to take care of the short comings of MS-DOS.

Some reasons why CVS is better to Subversion simply don't hold up once you understand the reasoning:

• In CVS, tags and branches were two completely different concept. Actually, there wasn't much difference between a tag or a branch. In the CVS ,v file, branches and tags were both aliased to particular revisions at the beginning of the file. In fact, you used the same command: cvs tag to create a branch or a tag. It's one of the reasons why Subversion didn't make a distinction between the two concepts. However, by treating branches and tags alike, Subversion did give you a way to track the history of a branch or tag. Who created it and when? What revision was it based upon? Did it get changed? Subversion also gives you an easy way to see all of the tags or branches in your repository. In CVS, you have to go through each and every file.
• CVS is more flexible than Subversion because Subversion more or less forces you to work in entire directories. In CVS, you could check out hither and thither, make your changes, and then tag them all at once. Of course, this is really a bad, terrible, awful, dangerous way to work. What usually happens is that you're told to do a build based upon an old tag, but then put these half dozen or so file changes in. Then, create a new tag. Fun and excitement happens when you attempt to follow these directions. Did you make the new tag on revision 1.3.4.2.3.2.5.2 or 1.3.2.4.3.2.5.2?
• CVS allows you to have sparse tagging and branching. You can have a base tag, then add other tags on top of that. Of course, the reason most sites did this is because it could take hours to branch or tag a really big CVS repository. Subversion does the same thing in a microsecond.
• CVS uses standard RCS file format, so you can fix problems in your repository. However, most of the time, you end up creating more problems than you're fixing.

CVS was a great improvement over RCS. In CVS, you didn't have to lock a file before changing it. In CVS, you could checkout entire subtrees without writing some sort of system front end. RCS was developed to version individual files. CVS versioned your entire repository as a single project.

RCS itself was an improvement on SCCS. RCS repository format was easier to understand. Keyword expansion worked better, and was less cryptic. You could have branches of branches while SCCS left you with only a single branch level. RCS had the built in concept of tags while SCCS required you to track tags yourself.

And SCCS was much better than not using a source repository at all.

The truth is that CVS has been replaced by Subversion, since Subversion came out over a decade ago, all work on CVS has ground to a halt. I don't even think bugs are being fixed any more on CVS.

Lassa

Fixing bugs on CVS would likely break the workflow for the people who still use it, which are very likely to rely on them being present. – Ruebenrueda

From a highly experienced CVS and Subversion user, Subversion mostly swapped one set of issues with CVS to another set when used with complex projects. SVN "fixed" some things and introduced complexities and other issues. Seriously approaching use of Subversion vs. CVS was a big "no" for me. I'd prefer CVS or any other DVCS over Subversion, but in the end, the answer that says CVS still is viable is a legitimate response. CVS 12.x is stable enough that distributions are shipping it, and it even does version commits (in addition to per-file versioning). – Kara

@Kara What specifically do you think CVS does better than SVN? Having used both reasonably extensively, I can’t think of one single thing that CVS does better, and the fact that CVS doesn’t store a version for the project as a whole (unless you specifically create a tag) makes it basically unsuitable for modern development, since single-file projects are uncommon these days. (Of course, these days, DVCSs are the way to go.) – Hamal

Whether or not one one likes agrees with this, there are still niche cases where CVS can be useful in a modern age (though this is not meant to advocate for use of CVS over a more modern VCS.) It is rather haughty to assume one knows use cases for all people everywhere. Really there is no merit in arguing this. – Kara

@Kara Great, so if I’m ignoring a use case that CVS serves better than SVN, then say what that use case is, don’t just accuse me of being “haughty”. I’d actually like to know what such a use case would be. – Hamal

Answer 3

Only thing that I have come across in my limited use of CVS is that CVS treats branches and tags as different and also treats them as what they are and not as just folders that SVN does. There are specific commands for these and they are treated as first class citizens of the version control system. How do you create a branch in SVN? svn copy. Tag? same. What is the difference? Nothing really, except how you treat them. While one can say that SVN's model leads to simplicity, it causes various tools to misunderstand them and not get the context of the folders. If you see Git, it is similar to CVS in this manner.

But definitely, there is no reason to use CVS now-a-days, apart from legacy reasons. Many say that SVN was build to be a better CVS and in almost all aspects SVN is better and is widely used.

Inlet

Across-the-board statements like this are really annoying. Keith Thompson's answer is correct, and aside from legacy reasons, I still find CVS useful and SVN a worse option these days. I'd much rather use CVS or a number of the newer DVCS over SVN. It created all kinds of issues in the name of "fixing" CVS, and as a heavy user of both tools, I'd never choose to submit to the set of issues SVN created for itself (i.e. duplicating storage of the entire repository for tagging, and more, which I'll not describe in detail here). – Kara

@Kara You realize that an SVN tag isn’t actually a duplicate, right? It appears to the user as one, but behind the scenes, it’s just stored as something like a symlink. – Hamal

I might grant that SVN may have changed since it lost my vote, but I am well aware of how much more storage was consumed when using it, and it did involve massive duplication in various cases. I'm not going to get into an argument of details. Lets not forget there is both a client-side and a server-side to consider. I note that you disagree, and I'm content to leave it at that. – Kara

@Kara Lightweight copying has been a core feature of SVN at least since I started using it around 2005 (and probably before that). If you’re criticizing something, make sure your criticisms are accurate. (I have since switched to Git, of course, so I haven’t used SVN recently.) – Hamal

Answer 4

CVS, git, and subversion have different workflow designs. It is inaccurate and misleading to say (git/subversion was designed to fix problems with cvs). Rather, subversion was written, because someone wanted a different workflow than CVS/RCS works best with. And then git was written because someone wanted yet another different workflow.

superficially, subversion and CVS are somewhat similar. Going from memory, CVS is good for those people who like to use RCS in their local code repository. RCS is nice in that it requires mandatory checking out of a file. It makes you explicitly aware of which files you are touching at any one time. It thus avoids you "accidentally" touching someone else's part of the code.

Toponymy

Downvoting because, as Luke Skywalker would say, "Amazing. Every word of that was wrong." – Hamal

wow. impressive. you dazzled me by your facts and logic. by which I mean, you wrote ZERO facts and logic, but downvoted anyway. Have you even USED CVS and RCS for work on a sustained basis? I have used all 3: CVS, RCS, and subversion, on extended projects, for work. – Toponymy

Yes, I've used both CVS and SVN on work projects. You want a list of errors you made? Here you go. "It is inaccurate and misleading to say (git/subversion was designed to fix problems with cvs)." WRONG. SVN was explicitly designed to be a better CVS (that is, to fix problems with CVS, but mostly work in a similar fashion). Git, OTOH, was designed for a different workflow. • "Going from memory, CVS is good for those people who like to use RCS in their local code repository." WRONG. CVS uses RCS files as its data storage format, but doesn't work like RCS. – Hamal

"RCS is nice in that it requires mandatory checking out of a file." WRONG. Mandatory exclusive checkout is not a nice feature. There's a reason that modern VCSs don't work this way. Also probably WRONG in that you imply that CVS works this way, which it doesn't: the C in CVS stands for "concurrent", because it doesn't require exclusive checkout. The idea of not touching "someone else's part" of the code is also problematic: all developers should be able to change anything necessary to implement what they're doing. – Hamal

Apparently, you dont understand the relative meaning of words like "nice", and "wrong". "nice" is a statement of opinion. The correct anti-response would be "i disagree that it is nice". Okay, you dont want mandatory locking. That's fine. Some other people DO want it, though. Grow up,and learn that there is more to the world, than just what YOU want to do, and what YOU need. – Toponymy