We are considering switching our source control repository at my work from Perforce to either CVS or SVN. I said that I didn't think CVS was as popular as SVN recently, and was met with a lot of blank stares. My boss told me that I must be still stuck inside the Windows-programming world if I was considering SVN, because most UNIX-based developers use CVS. In addition, another coworker said CVS was a lot more popular than SVN. To be honest, I haven't heard much about CVS at all. It seems like SVN is supported by pretty much every application / web service I use. Am I missing something here? I am really only familiar with using SVN, Perforce, and Git. Thanks, sorry for the lame question.
views:
1403answers:
22SVN for me but Git(Hub) is getting a lot of buzz these days. Check this out:
SVN vs CVS http://www.google.com/trends?q=svn%2C+cvs
Our organization strictly uses SVN. And yes, Git has been getting a lot of buzz lately.
From what I've seen at multiple client sites, CVS has been largely superceeded by SVN. Most (all?) of the major IDEs support it, and features like atomic commits are valuable. Most of the staff I meet are familiar with it as well. I'd be surprised to find a client now using CVS.
I don't have a study about the real usage of Subversion and CVS. But your boss is wrong, Subversion is widely used and also on UNIX-systems. Subversion is targeted as successor to CVS, and many projects switched from CVS to Subversion. CVS was once the mainly used version-control, but in that time all the alternatives from today didn't exists. Subversion, git, mercurial and bazaar were developed later.
The only thing is, that already a new sort of version-control-systems exists, the distributed VCSs. These VCS (namely git, mercurial and bazaar) has recently got many love by some projects.
But I don't believe, that any new project starts on CVS today. Subversion has nearly the same interface and does many things better than CVS.
From the SVN FAQ under the question Why does this project exist:
To take over the CVS user base. Specifically, we're writing a new version control system that is very similar to CVS, but fixes many things that are broken.
I think they've been largely successful in doing that. Git is relatively new, but I see little benefit of using for small- to medium-sized projects.
Every *nix server ships with CVS. You have to be a little more informed to use SVN. And it has to be installed first. These facts will affect the stats far more than "which is more popular".
Sourceforge added SVN. Now they are adding several more SCM systems.
Who cares which is the most popular?! Both have a large enough user base that they're not going to disappear overnight. Your decision should be based on which will do the job the best and not simply as a popularity contest.
Subversion was designed to fix some of the problems with CVS while maintaining a similar interface. They've largely succeeded which means that very few, if any, new projects use CVS and those that already use it seem to be considering migrating.
I cannot speak definitively, but of many places I've worked over the last 10 years, many have used Subversion. Several have used Perforce. None have used CVS (and I've never even heard of it being suggested seriously as an option).
(Side note: one place I've worked in in the last 10 years used Visual Source Safe. Perhaps unsurprisingly, they're out of business now.)
Anyone using CVS at this point should only be doing so because they're forced to, due to a situation where "that's just what we use". If you're selecting a new version control system, CVS shouldn't even be considered. Subversion does everything it does, except better. That was the whole point of SVN being written in the first place.
The relative popularity of the two systems shouldn't be used as a factor in deciding on one. Compare the features and take the one that suits your needs best. It won't be CVS.
Some more fair questions might be:
Are new repositories being set up more in SVN or CVS?
Are repositories changing more from CVS to SVN or the reverse?
The overwhelming answers, as far as I can tell, are that many more new repositories use SVN than CVS, and the migration is all from CVS to SVN.
There are arguments for keeping CVS if you already have it, but for virtually any other case I'd recommend SVN over CVS, and so would most of the people who use either heavily.
I think your team would really regret it if they chose to use CVS. The company I work for is in the process of moving from CVS to SVN there really is no competition between the two. The main feature of SVN that makes a difference for me is how it treats folders. CVS essentially only versions files, while SVN keeps track of both files and folders. For me, at least, this makes maintaining and organizing code easier since it streamlines adding directories to version control and moving files around inside the directories.
That being said, if you use a modern IDE (eclipse or netbeans are the two I have the most experience with) all of the details are covered up, and you will probably never notice the difference.
I don't know about "installed base", but from the (large) number of developers I know from the internet, SVN is quite popular, unlike CVS; but Git is quickly coming up as a possible new favorite.
Popularity isn't a good way to judge. Witness the horror that is Bugzilla, which still gets picked because it's popular. It's just awful. Ok, now that's out of the way...
CVS vs. SVN is like asking whether you should buy Chevy or Pontiac. They're essentially the same thing. Subversion has a couple of features that should have been added to CVS, but for daily operation you'll hardly notice any difference. Both are widely available and work fine, despite what some people who've never seriously used CVS have to say about CVS.
But you should really consider some of the other options like Git, Mercurial, etc. Distributed systems like those are useful even if you're all in the same office, or even if it's just you alone.
Your boss wants to insult you, but sadly doesn't know what he is talking about. People "still stuck inside the Windows programming world" are generally using SourceSafe, or perhaps something really expensive like ClearCase.
Subversion was developed with the goal of being a functional replacement for CVS, a goal which it pretty much succeeds at. Its probably OK to still use CVS if you are working an old project that already has CVS history. However, if you have a choice you should use SVN instead.
That being said, you still at the end of the day are stuck with something built around CVS's workflow. The latest generation of revision control systems are much different. For instance, distributed revision control systems have far better tools for anyone who might ever have to access sources remotely (does your company have branch sites?)
SVN.
That said, check these questions: subversion-vs-cvs, what-are-the-advantages-of-using-svn-over-cvs
Also note some projects that use SVN: Apache Software Foundation, KDE, Free Pascal, FreeBSD, GCC, Python, Django, Ruby.
At the company I work we tend to use CVS on most projects, if not all... I know there is a Subversion repo somewhere, but mainly used for non-source-code (diagrams and documents). Why this is so is a great mystery to me. I have had lengthy discussions with a colleague about Subversion and how much better it is compared to CVS. We even tried to convince our boss to move all of our project's code (rather small in size, internal project) to SVN. But the effort was to no avail.
I am using SVN for almost everything, as far as my personal little projects go. And I wish someone had the sense to version all projects in Subversion at work too.
CVS is an relique from the previous millenium. There has not been any development on CVS for 10 years. That's an eternity in this business. The entire open-source world (except perhaps the Eclipse community) has moved on to modern source-control systems: Subversion, Git, Mercurial, Bazaar, and so on.
I'm a Windows developer and I've been using Subversion for about 3 years. Before I switched from Visual Source Safe, my first instinct was to use CVS because that was what I had used many years ago in college (on unix).
But after some amount of research it was clear even back then that most CVS folks were switching to Subversion, which is why I chose it. Plus Joel Spolsky made a very positive mention of it at one point on his blog I think, which heavily influenced my decision.
Ironically I think your boss and co-workers are the ones stuck in the Windows world. Most Windows folks probably assume all Unix folks use CVS because thats what they used many years ago in college. Today, anyone who hasn't heard of Subversion probably doesn't keep up with what is happening in the development world.
To be honest, SVN was supposed replace CVS, but it's branching model is very close to VSS, and thus total shit.
If I was given an option between CVS and SVN I would chose CVS.
The good thing is that you have other choices. At the time I started to configure my personal setup, I chose mercurial because I felt that git was not yet ready on Windows.
If you can I would try to steer the bosses to mercurial or git. If they aren't happy with those then I hear that BitKeeper or Clearcase would also be good alternatives ( but don't have experience with them ) but they are expensive, and BitKeeper has a wakadoo writing it's license.
I've heard good things about Team Foundation, SVN, Git, bazaar, and mercurial.
I've used CVS, Clearcase, mercurial, SVN, and a little bazaar.
I'm not really on-board with the distributed version control systems; they sound like a nightmare for software engineering and controlling versioning for a product release. Of the dVCS, I prefer mercuruial(aka hg), due to the user-friendly docs.
I would recommend SVN for modern development.