Subversion vs CVS

I've used both SVN and CVS a little bit, but will need to choose one for a new project I will be starting.

Can anyone who has used both extensively please offer some pros and cons and which they think is better? Best learning resources would be appreciated too.

This will be for a small project, just one or two developers to start.

I've used both. There is no comparison; you want svn. The only reason to use CVS is because you are entering or taking over a legacy system with management that does not want to change the status quo. If you are starting on a new project, it is virtually a logical impossibility to argue that CVS is better than Subversion.

If you google around, you should find plenty of comparisons, and rationales for using Subversion over CVS. Some of the advantages of Subversion over CVS:

• can move or rename files or directories cleanly
• atomic commits
• "cheap" copying and branching
• commits are changesets on the whole tree (not just histories on individual files)

Having said all this, I recommend you also explore some of the distributed VCSs like Bazaar, Mercurial and git. I personally use git on all my projects.

Subversion has some substantial wins over CVS:

1. good remote options http/https/svn vs pserver
2. atomic commits
3. ubiquitous tool support
4. rename
5. directory versioning

However it has serious shortcomings. The biggest by far is that Branches and Tags are not first class citizens in svn, they are just directories that adhere to a convention. In addition to losing some of the benefits of real branching and tagging (mentioned in other comments) the biggest problem it creates is that if makes it very easy to screw up.

Subversion's use of convention rather than configuration means that you need to think about your repositories structure in advance and ensure that everyone adheres to it. Else you create a world of hurt for future generations, let alone any tools that need to grok your repo.

Merging and mirroring were almost non-existent (well assistance for) pre 1.5. 1.5 has taken steps to address both of these, but there is still room for improvement. Merging in subversion is still way harder than it needs to be.

SVN over CVS is almost a no-brainer. However, you would be remiss not to at least consider what DVCS's have to offer (Git, Hg, Bzr) or if your budget allows there are commercial tools with excellent reputations (Accurev, Perforce).

Subversion is probably the right choice, but you must do your homework to get the best results. Start with the Red Book http://svnbook.red-bean.com/

Although I would choose Subversion over CVS in most cases, you should know what you're missing with Subversion:

• CVS sees tags and branches as different things; Subversion doesn't. This means that third-party tools built on top of Subversion (e.g. IDEs with source control integration) have a harder job knowing the difference. You usually have to do some special configuration to tell it where your tags and branches are, and you have to make sure that your users stick to a certain filesystem layout.

• Subversion can't look at a file and tell you at what point someone created a branch or tag from it. Tools like CVSGraph can use this information to draw a tree of a file's history. To do that with Subversion, you'd need to search all the branch/tags directories, and I haven't seen any tools that do this well.

• CVS has been around longer, and the third-party tools are more stable, in my experience.

Call me old fashioned, but I much preferred the branching/tagging model under CVS.

In CVS, branches and tags are different things. A tag is a label for a revision. They are super-useful for things like marking a PRODUCTION tag for files to sync to your webserver. You don't have to merge to update the PRODUCTION files -- you just move the tag.

Branches live in the same 'namespace' as the main file -- it's easy to track down all the mods of a particular file.

In SVN there is no such things as a tag. There's only branches. If you want tags, you need to create a branch and pretend it's a tag. Branches are basically copies of files. Last time I used SVN for branches/merges, you had to record the revision of the pre-branched file if you ever hoped to merge it back together (note, I'm not an SVN expert, so this may have changed).

That being said, I think SVN is better in every other respect and you probably shouldn't start a new project with CVS.

You're going to get a lot of answers to this, I suspect. They might even all agree.

Between those two choices, I believe there is no question that you should use Subversion. Subversion was built as a "better CVS" and as a result, nobody actively maintains CVS any longer. Subversion has the ability to rename and move files without losing history, supports atomic commits, has a more robust repository format, has more modern access methods, has better third party tool support, and the list goes on.

Subversion is like `a better CVS'. It handles moving files AND directories well. It has branching support, although that is inferior to Distributed VCSs.

You may also consider using a distributed VCS one like git, bazaar or mercurial.

Edit: Here is a link to a similar question

Generally Subversion .. However you should watch out for resource issues.

When I was working for a game company we had a few directories containing hundreds of tiny files, and other directories that contained a few hundred meg files. When we swapped from CVS to Subversion, the speed of checking out the repo decreased from one hour to four or five hours. Updating was also substantially slowr.

This is almost certainly due to using either http or ssh to transmit file data, compared to the native csv pserver, however since it is so easy to setup svn over ssh or webdav people tend not to think about the protocol overhead. You can however use a native svn protocol and this should alleviate the issue, we did not test this at my old company.

Another issue that is often ignored is storage space, we found that subversion did use several times as much storage locally as CVS. I seem to recall that it stores a local copy of the repo data to speed up diffing, this won't be a huge issue unless you store several gigabytes in your repository.

I have used subversion for 3.5 years, now I moved to other company who uses CVS for source control. At first, there are not many differences between the two, but coming to merge operation (which is the top most of my concerns) I could say that CVS did a better job. The concepts of branches/tags in SVN are confusing while very clear in CVS. also merging (in my case, integrating a branch) is much easier in CVS than in SVN. The weakness of CVS is so far in my idea only the atomic commit. otherwise, it would be good choice.