I'm trying to create and follow best practices for versioning control and came across a reference to atomic commits in subversion. Since I've never heard of this action, I have a few questions about it.
Thanks for your help.
John
There is no special command for atomic commits. Every commit in subversion is atomic.
What this means is, that every commit (of any number of files) will either succeed or fail as a whole.
It's not possible that only some of the commited files make it to the repository and others not (e.g. because of an error that occurred in the middle of the commit operation or a conflict in one of the files).
This is the same for TortoiseSVN, since it builds on the "normal" subversion functionality.
The following is an excerpt from the subversion book:
An svn commit operation publishes changes to any number of files and directories as a single atomic transaction. In your working copy, you can change files' contents; create, delete, rename, and copy files and directories; and then commit a complete set of changes as an atomic transaction.
By atomic transaction, we mean simply this: either all of the changes happen in the repository, or none of them happens. Subversion tries to retain this atomicity in the face of program crashes, system crashes, network problems, and other users' actions.
The "atomic" in this case refers to an atomic operation. You can find a good definition of that here: http://en.wikipedia.org/wiki/Atomic%5Foperation
All commits in SVN are automatically atomic, so you get it for free everywhere you do a commit.
If you want to know what atomic commits are good for, imagine that you merge a branch into the trunk on your disk. You start in the morning and after lunch you're done, everything compiles, and all unit tests run successfully. You then commit the 200+ files changed during that merge.
In SVN, either the commit succeeds and all 200+ files are committed in one go or the commit fails and no changes at all were made to the repository. (There isn't much more to say about this. It's just the way it always should have been.)
In CVS, which doesn't have atomic commits, it can happen that your commit is interrupted after 150 files because someone stumbled over your network cable, with the remaining 50+ files not being committed, leaving the repository in an intermediate state. While you try to plug in your network cable, someone else in your team checks in another set of changes. That set of changes is disjoint from the ones you already checked in, so the other person's commit succeeds. However, the changes are incompatible. Now the team is stuck with a repository that contains code that doesn't even compile, let alone passes any test. What's worse: the two of you have a team manager breathing down your neck to fix those incompatible changes as fast as possible so the rest of the team can stop playing Quake and get back to work.
Surprisingly, such scenarios are not as unlikely as it might seem. I've been there several times and got my collection of lousy shirts.
Hi John, To understand the true use of atomic commit, read this about continuous integration:
http://en.wikipedia.org/wiki/Continuous_integration
The use is really about ensuring that you can undo all the changes of a specific developer in case of integration issue. This is a very powerful feature in keeping the integrity of the code in repository.