The fundamentals of source control essentially boil down to two elements: Repositories and Working Copies. All activities perfomed using source control involve interaction with one or both of these elements.

The repository is the ultimate source of truth in the system. It contains the latest version of every item under source control. Additionally it contains a history of all the revisions of each item. This allows the state of the repository at any point in time to be recreated. By querying the repository you can determine such things as what changes were made in particular time periods, what changes a specific developer has made, and what changes were submitted to the repository at the same time.

Source control users do not edit the items in the repository directly. Instead they work with a local copy that is specific to them. This is known as the working copy. Different source control systems place different limitations on developers may change their local copies (these will be discussed when I get to checkout models) but the basic principle that developers use a working copy remains constant. Once their changes are done they submit them to the repository. This makes the changes the latest version of the item, and therefore the current source of truth for these items.

This submission is generally called checkin, and is performed using source control client software. This software may be integrated into the users IDE or a standalone application (or both). It is responsible for communication with the repository using mechanisms which are generally unimportant to the end user. The other key responsibility of the client is to pull down changes from the repository to the working copy.

The checkin and get operations form the basis of source control operation. Using these operations it is possible to reliably distribute your updates to other team members and to receive their changes in turn. By providing a source of truth the source control system eliminates ambiguity as to what the latest version is considered to be. A modification that exists only in a working copy is not considered an official part of the software system, being only a draft that may be further modified or discarded.

Unfortunately the checkin/get model is not sufficient in practice. Development teams working on a codebase will produce modifications that conflict or are incompatible. Therefore a source control system needs mechanisms to resolve these conflicts. I will be discussing these mechanisms in my new source control post.