Atomic commit: Difference between revisions

Revision as of 16:01, 23 October 2016

Revision as of 04:21, 11 February 2018

Line 32:

==Revision control==

The other area where atomic commits are employed is [[revision control]] systems. This allows multiple modified files to be uploaded and merged into the source. Most revision control systems support atomic commits ([[Concurrent Versions System|CVS]], [[Microsoft Visual SourceSafe|VSS]] and [[IBM Rational ClearCase]] (when in [[IBM Rational ClearCase UCM|UCM]] mode)<ref>http://pic.dhe.ibm.com/infocenter/cchelp/v8r0m0/topic/com.ibm.rational.clearcase.ccrc.help.doc/topics/u_checkin.htm?resultof=%22%61%74%6f%6d%69%63%22%20%22%61%74%6f%6d%22%20%22%63%6f%6d%6d%69%74%22%20{{dead link|date=October 2016 |bot=InternetArchiveBot |fix-attempted=yes }}</ref> are the major exceptions).

Like database systems, commits may fail due to a problem in applying the changes on disk. Unlike a database system, which overwrites any existing data with the data from the [[changeset]], revision control systems [[merge (revision control)|merge]] the modification in the changeset into the existing data. If the system cannot complete the merge then the commit will be rejected. If a merge cannot be resolved by the revision control software it is up to the user to merge the changes. For revision control systems that support atomic commits, this failure in merging would result in a failed commit.