Each file under version control has a change history that consists of an initial version and a series (or sometimes a branching tree) of subsequent revisions.
To make a file version-controlled, you must register it; that is, you must tell the version control system to treat the file contents you’re starting with as an initial version and begin maintaining a change history for it.
To change a registered file, in the old days you’d have to check out the file. Doing so notifies the version control system that you’re modifying it. Under SCCS and RCS, this would lock the file so that no one else could check it out until you were done (anyone else could still look at it, though). This limitation was one of the major motivations for the development of CVS, the Concurrent Versions System, which doesn’t make locks. Instead, it tries to reconcile any concurrent changes at the time that they are committed, as described below. Even so, some developers prefer to configure CVS to keep files locked at the OS level until they consciously decide they want to make changes to one of them; this largely mimics the RCS experience, albeit on a voluntary basis.
In a system like SCCS or RCS that uses locking, you may sometimes find that you can’t check out a file because someone else has it locked already. Perhaps that person checked it out and wandered away, so that the lock is stale. You may want to steal the lock—that is, seize control of the work file with whatever changes ...