One of the reasons why programmers prefer SVN over CVS is the former allows atomic commits ? What does this mean ?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
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.
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:
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.