Description
The VCS should support atomic commits. This means that if a committer wishes to commit n files at once, either the commits to all n files succeed, or they all fail.
It should be impossible for a commit designed to affect multiple files only affect a subset of those files.
This will remove the race condition that sometimes occurs when users (or the tinderbox) update the source tree in the middle of a lengthy commit, and retrieve an inconsistent copy of the tree.
Note: this will not prevent developers from creating inconsistent copies of the tree, by, eg., committing a single logical change as two separate changes.
Current Implementation
CVS does not implement atomic commits. The closest we currently get is the work carried out by log_accum.pl, which attempts to generate only one log message per change.
SVN Implementation
Atomic commits are fully supported by Subversion. A single commit either succeeds or fails.
Hg Implementation
It's all atomic.
Git Implementation
It's all atomic.
Monotone Implementation
Supported (also see monotone:FeatureAtomicCommit)
Monotone commits are atomic and each produces a discrete revision.
In addition, you can commit at any time to record the current state of your workspace safely. Monotone supports (and encourages) multiple heads. You don't have to worry about whether your workspace or repository are up to date with respect to other developers' changes, and you don't have to be interrupted by a need to merge your work with other changes before you can commit. Merging happens as a separate step, when you are ready, and you can always go back to the starting point you just committed if the merge turns out to be difficult.