Version Control Systems

Revision control (also known as version control system) is the management of multiple revisions of the same unit of information. It is most commonly used in engineering and software development to manage ongoing development of digital documents like application source code, art resources such as blueprints or electronic models, and other critical information that may be worked on by a team of people. Changes to these documents are usually identified by incrementing an associated number or letter code, termed the "revision number", "revision level", or simply "revision" and associated historically with the person making the change.

Concurrent Version Systems (CVS)

In the field of software development, the Concurrent Versions System (CVS), also known as the Concurrent Versioning System, provides a version control system based on open-source code. Version control system software keeps track of all work and all changes in a set of files, and allows several developers (potentially widely separated in space and/or time) to collaborate. Complete information about CVS can be found at http://ximbiot.com/cvs/

Subversion (SVN) Subversion

(SVN) is a version control system initiated in 2000 by CollabNet Inc. It is used to maintain current and historical versions of files such as source code, web pages, and documentation. Subversion is well-known in the open source community and is used by many open source projects such as: Apache Software Foundation, KDE, GNOME, Free Pascal, GCC, Python, Ruby, Samba and Mono. SourceForge.net and Tigris.org also provide Subversion hosting for their open source projects. There is also adoption of Subversion in the corporate world. In a 2007 report by Forrester Research, Subversion was recognized as the sole leader in the Standalone Software Configuration Management (SCM) category and strong performer in the Software Configuration and Change Management (SCCM) category. Subversion is released under the Apache License, making it free software. Complete information about SVN can be found at http://subversion.tigris.org/

Features of CVS/SVN

Both CVS and SVN use client-server architecture: a server stores the current version(s) of a project and its history, and clients connect to the server in order to "check out" a complete copy of the project, work on this copy and then later "check in" their changes. Typically, the client and server connect over a LAN or over the Internet, but client and server may both run on the same machine if CVS/SVN has the task of keeping track of the version history of a project with only local developers. Several developers may work on the same project concurrently, each one editing files within their own "working copy" of the project, and sending (or checking in) their modifications to the server. To avoid the possibility of people stepping on each other's toes, the server will only accept changes made to the most recent version of a file. Developers are therefore expected to keep their working copy up-to-date by incorporating other people's changes on a regular basis. This task is mostly handled automatically by the CVS/SVN client, requiring manual intervention only when a conflict arises between a checked-in modification and the yet-unchecked local version of a file. If the check-in operation succeeds, then the version numbers of all files involved automatically increment, and the CVS/SVN-server writes a user-supplied description line, the date and the author's name to its log files.

Listed down are the common terminologies used in the world of Version Control Systems:

Branch

• A set of files under version control may be branched or forked at a point in time so that, from that time forward, two copies of those files may be developed at different speeds or in different ways independently of the other.

Change

• A change (or diff, or delta) represents a specific modification to a document under version control. The granularity of the modification considered a change varies between version control systems.

Change list

• On many version control systems with atomic multi-change commits, a changelist, change set, or patch identifies the set of changes made in a single commit. This can also represent a sequential view of the source code, allowing source to be examined as of any particular changelist ID.

Check-out

• A check-out (or checkout or co) creates a local working copy from the repository. Either a specific revision is specified, or the latest is obtained. Commit A commit (check-in, ci or, more rarely, install, submit or record) occurs when a copy of the changes made to the working copy is written or merged into the repository.

Conflict

• A conflict occurs when two changes are made by different parties to the same document, and the system is unable to reconcile the changes. A user must resolve the conflict by combining the changes, or by selecting one change in favour of the other.

Export

• An export is similar to a check-out except that it creates a clean directory tree without the version control metadata used in a working copy. Often used prior to publishing the contents.

Head

• The most recent commit.

Import

• An import is the action of copying a local directory tree (that is not currently a working copy) into the repository for the first time.

Label

• See tag.

Mainline

• Similar to Trunk, but there can be a Mainline for each branch.

Merge

• A merge or integration brings together two sets of changes to a file or set of files into a unified revision of that file or files.

• . • This may happen when one user, working on those files, updates their working copy with changes made, and checked into the repository, by other users. Conversely, this same process may happen in the repository when a user tries to check-in their changes.
  • • It may happen after a set of files has been branched, then a problem that existed before the branching is fixed in one branch and this fix needs merging into the other. • It may happen after files have been branched, developed independently for a while and then are required to be merged back into a single unified trunk.

Repository

• The repository is where the current and historical file data is stored, often on a server.

Resolve

• The act of user intervention to address a conflict between different changes to the same document.

Reverse integration

• The process of merging different team branches into the main trunk of the versioning system.

Revision

• Also version: A version is any change in form. In SVK, a Revision is the state at a point in time of the entire tree in the repository.

Tag

• A tag or label refers to an important snapshot in time, consistent across many files. These files at that point may all be tagged with a user-friendly, meaningful name or revision number. See the discussion of baselines, labels, and tags.

Trunk

• The unique line of development that is not a branch (sometimes also called Baseline or Mainline)

Update

• An update (or sync) merges changes that have been made in the repository (e.g. by other people) into the local working copy.

Working copy

• The working copy is the local copy of files from a repository, at a specific time or revision. All work done to the files in a repository is initially done on a working copy, hence the name. Conceptually, it is a sandbox.

Comparison between CVS and SVN

1. Support for atomic commits

CVS: No support

SVN: Commits are atomic

2. System support for moving a file or directory to a different location while still retaining the history of the file?

CVS: No. Renames are not supported and a manual one may break history in two.

SVN: Yes. Renames are supported.

3. System support copying files or directories to a different location at the repository level, while retaining the history?

CVS: No. Copies are not supported.

SVN: Yes. And it's a very cheap operation (O(1)) that is also utilized for branching

4. Propagation of Changes from one repository to another

CVS: No

SVN: yes

5. Is it possible to define permissions on access to different parts of a remote repository? Or is access open for all?

CVS: Limited. "Pre-commit hook scripts" can be used to implement various permissions systems.

SVN: Yes. The WebDAV-based service supports defining HTTP permissions for various directories of the repository.

6. Does the repository support changesets?

CVS: No. Changes are file-specific.

SVN: Partial support. There are implicit changeset that are generated on each commit

7. Does the version control system have an option to track the history of the file line-by-line?

CVS: Yes. cvs annotate

SVN: Yes. (svn blame)

8. Does the system have a way to assign a per-file commit message to the changeset, as well as a per-changeset message?

CVS: No. Commit messages are per change.

SVN: yes

9. What are the licensing terms for the software?

CVS: GNU GPL (open source)

SVN: Apache/BSD-style license. (open-source)