When committing, Subversion merges the changes made in a working copy with the latest version in the repository. Likewise, when updating, changes from the repository are merged with the files in your working copy.
This process works well for most text files. However some text files (such as some XML formats) can be rendered unusable (i.e. corrupted) by the merging of changes. Worse, most binary file formats (images, word processing documents etc.) can’t be merged at all.
As a result, Subversion will not attempt to merge changes to binary files when committing or updating a working copy. While this avoids file corruption, it doesn’t solve conflicts which occur when two team members modify the same file in parallel. In such situations, the last commit will overwrite all previous changes made by other team members.
Locking is Subversion’s solution to to prevent users from overwriting each others work when working in parallel on the same file.
Locking a file (directories can’t be locked) results in a lock being recorded in the repository that will prevent other team members from committing changes until unlocked. Other team members can see the file’s locked status when browsing the repository. The lock is also propagated to the working copies of other team members when they next update the file.
While this locking mechanism prevents edits from being overwritten by a later commit, it doesn’t prevent team members from making changes in parallel. An attempt to commit changes to the repository will simply fail, leaving the unfortunate team member with no choice but to manually integrate her changes into the newer version in the repository.
For this reason, Subversion allows the user to specify that a file must be locked before it can be edited. This is done by setting the value of the svn:needs-lock property to Yes.
Once set, the svn:needs-lock property will cause the file to be marked read-only in the file-system, thus preventing users from inadvertently changing the file before it is locked, at which point the read-only status is removed.
The user can of course circumvent this protection by removing the read-only state using the Finder or command-line. However an explicit action is required and they have nobody to blame but themselves when they overwrite other people’s work when committing these changes to the repository.
By default, files are unlocked when modifications are committed to the repository. This behavior can be overridden for each commit using the Unlock files after commit option in the commit view.
If you would prefer to always leave files locked after committing changes to the repository then change the value of the Unlock files when committing option in the app’s preferences.
A locked file can also be unlocked either directly in the repository or in a working copy.
Unlocking a file which was locked by another user is termed breaking their lock. Locking a file which belongs to another user is called stealing their lock.
Locks should generally only be broken or stolen in agreement with the lock owner. However the exclusive nature of locks means that there are instances (such as absence of the owner from the project) when stealing or breaking a lock is a necessity.