What is the value of atomic commits in Subversion?_问答_开发者

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.

What's its purpose?
When should it be used?
How is it differ开发者_高级运维ent than a normal commit?
Is it available to TortoiseSVN users? If so, how?

There is no special command for atomic commits. Every commit in Subversion is atomic.

It means 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 (for example, 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 idea is simply that changes to one file are usually related to changes in another. Some older version control systems didn't really handle multiple files in one commit (as an "atomic commit" as you call it) or they did so poorly.

You don't have to do anything special for this. That's just how Subversion works. But with Subversion you do have the option of checking in one file at a time or doing all the modified files at once or anywhere in between.

The idea of doing multiple files as one commit is that—generally speaking—you should be able to check out the repository at any particular version and it will at least compile and hopefully run. This is important in teams. Now in practice this might not be true 100% of the time but the guiding principle is sound.

So whether you do one file, all your changes at once or something in between what you're checking in should make sense as one commit. Like if you fix a bug and need to modify 8 files, check in all those 8 files as one commit with a message saying what bug you fixed and how you fixed it. It'll be easier to roll out later if there's a problem with it.

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_operation

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.

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.