Version control

Keeping track of changes in a document is easy as long as only one user is editing the document, on a single computer. In this case it would suffice to store a dated copy of the document once in a while. However, what if you give the document to two colleagues to allow them to proof-read it? You will receive two altered copies back – three if you worked on it in the meanwhile. How do you get all the changes back into a single document? One solution is to simply only allow one person to edit the document at a time, but this can sometimes be unproductive. This is a problem programmers have faced on a large scale for many years and over time they have developed a solution to it that allows everyone to edit the document simultaneously: Version control. This software provides the latest developments in version control programmers and provides it for lab journal editing.

Version control requires that each copy of the document are given a formal version number. How this works will be illustrated by an example: User Alice creates a new document and starts writing it. Once her working day is over, she sends it out for others to edit it if they wish. The document history at this point simply looks like this:

	(1)*
This document is viewed by several people, but only Bob and Charlie decide to edit it. It now looks like this:
	(2)* ← (1) → (3)*
(should one show the edit tree on each computer?) Bob sends his changes back. In this case Alice can easily just step up to his latest version, because it is the latest available for her. For Alice it looks like this:
	(2)* ← (1)
Now Charlie sends his copy, and since it does not stem from the latest from Alices point of view (2), it means that it contains conflicting changes and these conflicts must be resolved. Alice takes the changes in (2) and (3) and merges them, and produces a new document:
	(2) ← (1) → (3)
	    →  (4)* ← 
The new document (4) joins the two versions, and restores there being only one latest copy. Some terminology from version control should be introduced here: The act of assigning an edited document a version is called committing. A version is called a branch (as on a tree) Joining branches is also called merging, and handling the differing changes is called conflict resolution. When merging only requires picking the latest version (as in going from 1 to 2), it is called a fast forward. The final branches in a version history are called heads. There is always at least one head, and if there are several, they must at some point be merged.

Much of the work is done by the software. Before you send a document to someone else, the latest version of the document must have been given a version, that is, you will be asked to commit it. As long as you receive versions which are direct descendants of the previous one, fast forwards will be done automatically. The only time you will need to take action is whenever documents must be merged.

The software does it's best to merge automatically but you must always approve the new version, and sometimes help with the merge (e.g. if two authors disagree on how a piece of text should be revised, you have to pick which way). However, as long as changes are not done at the same place, the software should be able to figure out how to best merge the documents.