In software development revision control, also known as version control and source control is a management tool of changes to documents, source code, resource, and any other collections of information. It is a repository where every change made to file is tracked and stored.
In software development process, software can change and identified by its version usually by a number or letter code (which is called as “revision number”, “revision level”, or simply “revision”). For example, an initial set of files is “revision 1”. When the first change is made, the resulting set is “revision 2”, and so on. Each revision is associated with a timestamp and the person who make the change. Revision can be compared, restored, and merged.
When the size of project become larger and/or the changes periodically become often, a need to organize and control revision exists. Revision can be done manually such as creating a directory for each version. However, this solution has side effect: inefficiency. One would has time to check the changes and merge involving files to create a revision. And also the size would be too large to handle. Let say an initial project has size 100MB, if we do the solution before we would have 1GB alone for 9 revision we have (at roughly). A simple idea comes: what if we only save the changes made to a file? But this won’t be ineffective if done manually. Thus, a revision control software create to manages the version.
Revision Control Software (later referred as RCS) most commonly run as stand-alone applications, but revision control is also embedded in various type of software such as word processor and spreadsheet. However in this context we only discuss about stand alone RCS.
We could say that version control systems are essential for any form of distributed, collaborative development. Now, dozen of revision control software exists. Let see what revision control software capable of in general.
A change can be made by one man and might also vary from time to time. Also a change can be made by many developers at a time. Developers may wish to compare one version to another version (ex: today version with yesterday version) or maybe a change made by different developers for a same module.
Knowing what, who, and when of the changes might help, for example comparing performance of particular version, solve bugs when occurred, and so on. Note that RCS will track those changes, thus when problems arouse from a change one can examine who made the change and the reason they gave for making the change.
Nobody is perfect, including developer. One might do a mistake (intentionally or not), and it can also happen in editing source code. Although there is a facility named undo, it might won’t be a help. For example: you edit a source code in a night and when you check the other day you realize you have done something wrong and forgot all what you have change. Undo command might help you when you still open and edit the file, however when you close the editor it will be different case.
A revision control might have a feature of “time machine”. Like implied by the name (although not a magical thing happen here) it can bring you back to a version or situation before you do changes. You simply make a checkpoint, or a milestone. Whenever you want to go back, you refer to that checkpoint and RCS will revert the change to the condition in checkpoint.
Resource development is usually carried out by teams, either co-located or distributed. RCS is central to coordinating teams of contributors. It lets one contributor work on a copy of the resources and then release their changes back to the common core when ready. Other contributors work on their own copies of the same resources at the same time, unaffected by each other’s change until they choose to merge or commit their changes back to the project.
Typically in open source projects, RCS allow anyone to read and copy the project resources, but only authenticated users, known as committers are allowed to update source code in the repository.
Many activities in business are accompanied by a responsibility to perform ‘due diligence’ checks. Precisely what these checks entail will depend on the business activity in question, but with regard to intellectual property one important ‘due diligence’ activity is the tracking of the ownership of its constituent parts. So for example, if someone creates a piece of software and wishes his organisation to release it, his organisation will almost certainly want to check the provenance of all the code within the software. This process is facilitated by the ability to track who made which changes to the code, and when they were made. A version control system enables a list of contributors to be compiled and the dates of their contributions to be ascertained. Such a list can be easily cross-checked with a list of IP contracts.
Open development involves contributors making small regular changes to resources. A version control system provides a means for monitoring those changes as they occur. Automated systems will notify those responsible for managing the IP in project outputs. These notifications, coupled with the logs provided for each individual modification, allow project managers to monitor and trace all contributions.
Open development demands care concerning the provenance of the contributions. Open development projects need to follow best practice in this area. If an IP infringement is found to have occurred, the version control system can be used to determine the extent of the contamination (which files were affected by the problematic change), who performed the change and when they performed it. A version control system can even be used to recover the last uncontaminated version of the software.
Example of Revision Control Software
Let’s mention some popular existing Revision Control Software:
- Sub Version (SVN)
- Concurrent Version System (CVS)
- Git (http://git-scm.com/)
- CVS (http://www.nognu.org/cvs/)
- Subversion (http://subversion.apache.org/)
- Mercurial (http://mercurial.selenic.com/)