===== 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 [[http://venge.net/monotone/wiki/FeatureAtomicCommit|monotone:FeatureAtomicCommit]])

[[/Monotone|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.