What are the benefits of using SVN over CVS?

Question

My company uses CVS as our de facto standard for source control. However, I have heard many say that SVN is better.

I know that SVN is newer, but other than that, I am not familiar with its benefits.

I am looking for a good, concise comparison of the two systems, noting any advantages or disadvantages of each in the Java / Eclipse development environment.

Answer 1

CVS only tracks file-by-file modifications, while SVN tracks an entire commit as a new revision, which means it’s easier to keep track of your project’s history. Add the fact that all modern version control tools use the concept of revision, so it’s much easier to port from SVN than from CVS.

There is also a problem with atomic fixation. Although I only came across it once, it is possible that 2 people committing collaborative actions in CVS may conflict with each other, lose some data and put their client in an inconsistent state. When they are discovered at an early stage, these problems are not the main ones, because your data is still there somewhere, but it can be a pain in a stressful environment.

And finally, not many tools are being developed around CVS. While the new and brilliant new tools, such as Git or Mercurial, clearly lack tools, SVN has a fairly large application base on any system.

EDIT 2015 : Seriously, this answer is 7 years old. Forget SVN, use Git like everyone else!

Answer 2

One of many comparisons:

http://wiki.scummvm.org/index.php/CVS_vs_SVN

Now this is very specific to this project, but many things in general.

Pro Subversion:

• Rename / move version support (not possible with CVS): Fingolfin, Ender
• Supports directories natively: it is possible to delete them, and they are versioned: Fingolfin, Ender
• Version file properties; no more "executable bit" hell: Fingolfin
• A common version number greatly simplifies versioning and regression testing: Ender, Fingolfin
• Atomic commits: Fingolfin
• Intuitive (directory-based) branching and tagging: Fingolfin
• Simpler hook scripts (pre / post commit, etc.): SumthinWicked (I use it for Doxygen after commit)
• Prevents accidental committing of conflicting files: Salty-horse, Fingolfin
• Custom diff command support: Fingolfin
• Offline diff and they are instant: sev

Answer 3

SVN has 3 main advantages over CVS

• faster
• supports binary version management
• and adds transactional commit (all or nothing)

Answer 4

There is an application in the Subversion book that highlights important differences from CVS that can help you make your decision. These two approaches are more or less the same idea, but SVN was specifically designed to address the long-term flaws in CVS, so, at least in theory, SVN will always be the best choice.

Answer 5

I will repeat the proposal of Eridius Git, but I would expand it to another DRCS (Distributed Revision Control System) such as Mercurial and bazaar .

These products are fairly recent, and the level of equipment and integration with them seems to be low at the moment (based on my initial research). I would say that they are best suited for energy developers there (and here ;-)).

On the other hand, what does not CVS do for you? From your initial question, you actually don't have, "CVS sucks in this, what can I use instead?"

You must weigh the costs of any potential migration versus benefits. For an existing project, I think it would be difficult to justify.

Answer 6

We must not forget about the ecosystem. I worked in the CVSNT store, and by default, more and more open source tools were found that are supported by SubVersion.

Answer 7

btw: CVSNT supports atomic commits

Answer 8

As someone who is in the middle of the transition between CVS and SVN (initially we switched all our projects using cvs2svn and then decided that we would only switch using svn to new projects), here are some of the problems we had .

• Merging and forking are very different, and if you often switch and merge, if you do not have SVN 1.5 running on your server, you should know when you are branching (this is not very clear in the SVT Tortoise dialogs). Michael says that branching and merging is intuitive, I would say that after using CVS for 10 years, this is not so.
• If you are using an SVN server on Linux, it can be difficult to get your SA to switch to svn 1.5, since the default installation is 1.4.x.
• Unifying conflicts are not so easy or understandable (at least for me and my colleagues) in TortoiseSVN, as in TortoiseCVS. The approach to the three panels requires some getting used to, and WinMerge (my preferred merge tool) does not merge the three panels.
• Beware: many of the online tutorials and journal articles that I have read are obviously not shared or combined, you should set up your main repository as https://svn.yoursvnserver.com/repos/YourProject/Trunk and branches on https: //svn.yoursvnserver.com/repos/YourProject/Branches/BranchX . You can clean up if you run your repositories in the wrong place, but this leads to confusion.

Answer 9

You should take a look at Git instead of SVN. This is DVCS, which is fast and very powerful. It is not as convenient as SVN, but it is improving in this regard, and it is not so difficult to find out.

Answer 10

CVS (Concurrent Versions System) and SVN (SubVersioN) are two version control file systems that are widely used by teams working on the same project. These systems allow collaborators to track the changes made and to know who is developing which ones and whether to apply the branch to the main trunk or not. CVS is much older than the two of them and is a standard collaboration tool for many people. SVN is much newer and brings many improvements to meet the needs of most people.

Answer 11

you can also transfer only the latest code from CVS to SVN and freeze the current CVS repo. this will simplify the migration, and you can also create your legacy versions in the old CVS repo.

Answer 12

Well, some things that I feel make svn awesome.

• The combination of SVN-Altassian crucibles is a much more advanced method of review and quality control.
• Better Conflict and Merge Management
• This is obviously faster in order to accept checksums, commit, etc.
• The problem with atomic fixation. It is possible that 2 people sharing with CVS might conflict with each other, lose some data, and put your code base in an inconsistent state.

Migration can be easily completed in a few hours using cvs2svn.

Answer 13

GIT is the way to go now