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.

This is explained eg in Bye-bye CVS. I’ve been Subverted article written by Andy Lester:

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.