Locking

Subversion's «copy-modify-merge» model is optimal when users are collaborating on projects that consist of line-based text files, such as program source code. However, as discussed in Êîãäà áëîêèðîâàíèå íåîáõîäèìî, sometimes one has to use the «lock-modify-unlock» model instead of Subversion's standard concurrent model. When a file consists of binary data, it's often difficult or impossible to merge two sets of changes made in parallel by different users. For this reason, Subversion 1.2 and later offers a feature known as locking, often known as «reserved checkouts» in other version control systems.

Subversion's locking feature has two main goals:

• Serializing access to a resource. Allow a user to grab an exclusive right to change to a file in the repository. If Harry reserves the right to change foo.jpg, then Sally should not be able to commit a change to it.

• Aiding communication. Prevent users from wasting time on unmergeable changes. If Harry has reserved the right to change foo.jpg, then it should be easy for Sally to notice this fact and avoid working on the file.

Subversion's locking feature is currently limited to files only—it's not yet possible to reserve access to a whole directory tree.

Three meanings of «lock»

In this section, and almost everywhere in this book, the words «lock» and «locking» describe a mechanism for mutual exclusion between users to avoid clashing commits. Unfortunately, there are two other sorts of «lock» with which Subversion, and therefore this book, sometimes needs to be concerned.

• Working copy locks, used internally by Subversion to prevent clashes between multiple Subversion clients operating on the same working copy. This is the sort of lock indicated by an L in the third column of svn status output, and removed by the svn cleanup command, as described in «svn cleanup».

• Database locks, used internally by the Berkeley DB backend to prevent clashes between multiple programs trying to access the database. This is the sort of lock whose unwanted persistence after an error can cause a repository to be «wedged», as described in «Repository Recovery».

You can generally forget about these other sorts of lock, until something goes wrong that requires you to care about them. In this book, «lock» means the first sort unless the contrary is either clear from context or explicitly stated.