When a file is under version control, we say that it is registered in the version control system. The system has a repository which stores both the file's present state and its change history—enough to reconstruct the current version or any earlier version. The repository also contains other information, such as log entries that describe the changes made to each file.
The copy of a version-controlled file that you actually edit is called the work file. You can change each work file as you would an ordinary file. After you are done with a set of changes, you commit (or check in) the changes; this records the changes in the repository, along with a descriptive log entry.
A copy of a file stored in a repository is called a revision. The history of a file is a sequence of revisions. Each revision is named by a revision ID. The format of the revision ID depends on the version control system; in the simplest case, it is just an integer.
To go beyond these basic concepts, you will need to understand three aspects in which version control systems differ. As explained in the next three sections, they can be lock-based or merge-based; file-based or changeset-based; and centralized or decentralized. VC handles all these modes of operation, but it cannot hide the differences.blog comments powered by Disqus