Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Reasons to prefer CVS over SVN or Git [closed]

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?

like image 242
kay Avatar asked Oct 23 '11 22:10

kay


2 Answers

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.

like image 67
Keith Thompson Avatar answered Oct 12 '22 07:10

Keith Thompson


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.

like image 35
David W. Avatar answered Oct 12 '22 06:10

David W.