Version Control Basics
The Lock-Modify-Unlock Solution
Many version control systems use a lock-modify-unlock model to address the problem of different authors in a shared source overwriting each other's work.
In this model, the version control repository allows only one person to change a file at a time, and access is managed using locks. Harry must lock a file before he can begin making changes to it. If Harry has locked a file, Sally cannot also lock it, and therefore cannot make any changes to that file. All she can do is read the file, and wait for Harry to finish his changes and release the lock. After Harry unlocks the file, Sally can take her turn in locking and editing the file.
The Copy-Modify-Merge Solution
Subversion, CVS and a number of other version control systems use a copy-modify-merge model as an alternative to locking.
In this model, each user's client contacts the project repository and creates a personal working copy—a local reflection of the repository's files and directories. Users then work simultaneously and independently, modifying their private copies. In due course, the private copies are merged together into a new, final version. The version control system often assists with the merging, but ultimately a person is responsible for making it happen correctly.
When Locking is Necessary
While the lock-modify-unlock model is generally considered a hindrance to collaboration, there are still times when locking is necessary.
The copy-modify-merge model is based on the assumption that files are contextually merge-able: that is, the files in the repository are line-based text files (such as program source code). But for files with binary formats, such as artwork or sound, it is often impossible to merge conflicting changes. In these situations, it really is necessary for users to take strict turns in changing the file. Without serialized access, somebody ends up wasting time on changes that are ultimately discarded.