One of the reasons why programmers prefer SVN over CVS is the former allows atomic commits ? What does this mean ?
It means that when you do a commit to the version control system either everything you want to commit goes in, OR nothing does.
In CVS, when you try to commit it's possible for the commit to succeed on several files, then fail on several others (because they've changed). This leaves the repository in an unfortunate state because half of your commit isn't there, and it's likely that you've left things in a state where they won't compile or worse. Now you've got to hurry up and integrate whatever changes so that you can commit the other files before someone else needs to update and gets your broken set of changes.
In SVN this won't happen - SVN will either commit everything you've changed, or it will fail the whole changeset. Thus, you'll never leave the repository in a broken state due to commit issues.
If I try to commit in Subversion, but one of the files has a conflict, or is out-of-date, none of the files commits. In CVS, you’ve got a half-commited set of files that you have to fix RIGHT NOW.
The fact that CVS forces programmer to fix the merge immediately is as counter-productive as it gets. Compared to that, an option to delay / cancel / carefully merge changes is a substantial benefit.
Other benefits of SVN over CVS explained in above article are:
Local versions of everything you do
If you want to cvs diff, you have to be able to connect to your repository. No net connection, no diffing. Subversion stores local pristine copies of what you’re working on, so svn diff will work just fine. Want to start over? svn revert works unconnected, too.
Symbolic names of revisions
HEAD is the name of the tip of the trunk in CVS, but I’ve always wanted to be able to say “-r-1″ like I could way back when in PVCS days. With CVS, I have to do a cvs log on what I’m editing, and then subtract one. That’s no fun. With Subversion, I can say svn diff -r PREV.
Real status reporting
In CVS, the only way you can see if something on the server is newer is to cvs update and hope that whatever comes down doesn’t cause any conflicts. With the svn status command, I get real status, so I can see if there are conflicts BEFORE I do an update.
Helpful handling of merge conflicts
In CVS, if there are conflicts, you get conflict markers in your file. In Subversion, you get conflict markers, PLUS a copy of your original, pre-conflict file, PLUS the version that came down from the server, PLUS the version that you were originally editing. Then, you must explicitly svn resolve filename.txt to tell Subversion that you’ve fixed the problem. No more accidentally commiting back into CVS with conflict markers still there.
It means that all changes to all files are committed in a single transaction, so either all succeed or none.
This means that you are less likely to get partial edits checked in to the repository which cause builds to fail. You can still get people forgetting to check in all the relevant files, but that's a process issue rather than a problem with the versioning system.