Version control
Bugs or features of the software are often only present in certain versions (because of the fixing of some problems and the introduction of others as the program develops).
At the simplest level, developers could simply retain multiple copies of the different versions of the program, and label them appropriately.
Moreover, in software development, legal and business practice, and other environments, it has become increasingly common for a single document or snippet of code to be edited by a team, the members of which may be geographically dispersed and may pursue different and even contrary interests.
Sophisticated revision control that tracks and accounts for ownership of changes to documents and code may be extremely helpful or even indispensable in such situations.
Revision control may also track changes to configuration files, such as those typically stored in /etc or /usr/local/etc on Unix systems.
Two source management and version control packages that were heavily used by IBM 360/370 installations were The Librarian and Panvalet.
SCCS's user manual, especially the introduction, having been published on December 4, 1975, implied that it was the first deliberate revision control system.
After CVS, a dominant successor was Subversion,[8] followed by the rise of distributed revision control tools such as Git.
Concretely, one may print out a document, edit it by hand, and only later manually input the changes into a computer and save it.
In reality the structure is more complicated, forming a directed acyclic graph, but for many purposes "tree with merges" is an adequate approximation.
Thus, while the actual relations between versions form a DAG, this can be considered a tree plus merges, and the trunk itself is a line.
Indeed, "contract redline" and "legal blackline" are some of the earliest forms of revision control,[10] and are still employed in business and law with varying degrees of sophistication.
Centralized revision control systems solve this problem in one of two different "source management models": file locking and version merging.
Commits tell the revision control system to make a group of changes final, and available to all users.
The concept of a reserved edit can provide an optional means to explicitly lock a file for exclusive write access, even when a merging capability exists.
Typically only one of the terms baseline, label, or tag is used in documentation or discussion[citation needed]; they can be considered synonyms.
This results in some important differences from a centralized system: Rather, communication is only necessary when pushing or pulling changes to or from other peers.
Costs and benefits will vary dependent upon the version control tool chosen and the field in which it is applied.
This section speaks to the field of software development, where version control is widely applied.
Management effort may be required to maintain the discipline needed to follow best practices in order to obtain useful benefit.
[15] There can be damage mitigation, accountability, process and design improvement, and other benefits associated with the record keeping provided by version control, the tracking of who did what, when, why, and how.
[17] Previous versions can be installed and tested to verify conclusions reached by examination of code and commit messages.
The application of a test case to multiple versions can quickly identify the change which introduced a bug.
A change (or diff, or delta) represents a specific modification to a document under version control.
To commit (check in, ci or, more rarely, install, submit or record) is to write or merge the changes made in the working copy back to the repository.
Most revision control software uses delta compression, which retains only the differences between successive versions of files.
It is similar to checking out except that it creates a clean directory tree without the version-control metadata used in a working copy.
The process of merging changes made in the main trunk into a development (feature or team) branch.
The trunk is the unique line of development that is not a branch (sometimes also called Baseline, Mainline or Master[38][39]) An update (or sync, but sync can also mean a combined push and pull) merges changes made in the repository (by other people, for example) into the local working copy.
Update is also the term used by some CM tools (CM+, PLS, SMS) for the change package concept (see changelist).
