What are Version control systems ?

Version control system

• Also known as a Revision Control System 
• It is a repository of files.
• Every change made to the files is tracked, along with who made the change, when they made, why they made it and references to problems fixed, or enhancements introduced, by the change.
• Changes are usually identified by an incrementing number or letter code also known as revision number or revision.
• These systems are essential for any form of distributed, collaborative development.

Benefits

• Collaboration : A team of developers (which could be distributed geographically) may be working on the same set of files at once without interrupting each other's work. 
• Change management : The changes can be inspected, reviewed or rolled back as needed. For example, If you need the xyz.java as it was on May 17, 2008 - no problem ! 
• Tracking ownership : Every change is associated with the name of the person, so we know whom to give kudos to or ask questions. 
• Tracking evolution : Every change is associated with a short description, so you just need to pull a change log of some class to see how it evolved and who did what. 
• Branching : It is possible to create a copy (branch) of the entire project for some specific purpose (i.e.: prototyping or developing a fix for the important customer) without disrupting development workflow. 
• Continuous integration : Ability to split evolution of a software project into incremental changes allows to run all sorts of checks and tests against each incremental change in a continuous manner.

Version Tracking

Developers may wish to compare today’s version of some software with yesterday’s version or last year’s version.

Knowing the what, who, and when of changes will help with comparing the performance of particular versions, working out when bugs were introduced (or fixed), and so on.

Any problems that arose from a change can then be followed up by an examination of who made the change and the reasons they gave for making the change.

Coordinating Teams

Version control 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 changes until they choose to merge or commit their changes back to the project.

Any conflicts that arise - when two contributors independently change the same part of a resource - are automatically flagged when the changes are merged.

Common terms

• Repository : database server that contains all files and their history.
• Working copy : local version of files on somebody's machine. It may contain local unversioned changes.
• Trunk : home folder for some project within the repository. It usually contains all the latest changes.
• History (or ChangeLog) : a list of changes that were done to a file or folder since it was created.
• Latest (or Head) : latest available version of some file or folder.
• Revision : another word that means current version of file or folder.

Common operations

• Check out : first operation required to work with any repository. It involves creating working copy that mirrors some folder on the server (usually that's trunk).
• Commit (or Check In) : sending your local changes back to the server, so that other people can get them as well.
• Update : updating local working copy to have all the lasted changes that were committed to the server since the last time you've checked it.
• Revert : discard all your local changes to the working copy.
• Diff (or Change, Delta) : differences between two versions of the same file; or an operation involving actually looking up what was changed between two versions.
• Create patch : automatically create a file that describes all the changes that were done to the working copy (basically containing all diffs). Then these changes could be reviewed by somebody else and committed to the repository.

Advanced operations

• Conflict : It happens when somebody else changed the file, while you were working on it locally.
• Resolve : to fix contradicting changes by reviewing and manually merging them (VCSs can automatically resolve majority of the conflicts).
• Tag : to place a human readable label on some revision (i.e.: when releasing a product); or a noun representing such a label.
• Branch : to start a separate line of development over some old revision (i.e.: when fixing bugs for the previously released version).
• Merge : bringing together changes from different sources (i.e.: when applying a bug fix from some branch to a trunk).