We’ve seen how svn lock and svn unlock can be used to create, release, break, and steal locks. This satisfies the goal of serializing commit access to a file. But what about the larger problem of preventing wasted time?
For example, suppose Harry locks an image file and then begins
editing it. Meanwhile, miles away, Sally wants to do the same thing. She
doesn’t think to run svn status --show-updates
, so
she has no idea that Harry has already locked the file. She spends hours
editing the file, and when she tries to commit her change, she discovers
that either the file is locked or that it’s out of date. Regardless, her
changes aren’t mergeable with Harry’s. One of these two people has to
throw away his or her work, and a lot of time has been wasted.
Subversion’s solution to this problem is to provide a mechanism to
remind users that a file ought to be locked before
the editing begins. The mechanism is a special property: svn:needs-lock
. If that property is attached
to a file (regardless of its value, which is irrelevant), Subversion
will try to use filesystem-level permissions to make the file
read-only—unless, of course, the user has explicitly locked the file.
When a lock token is present (as a result of using svn lock), the file becomes read/write. When
the lock is released, the file becomes read-only again.
The theory, then, is that if the image file has this property attached, Sally would immediately notice something is strange when she opens the file for editing: many applications alert users immediately when a read-only file is opened for editing, and nearly all would prevent her from saving changes to the file. This reminds her to lock the file before editing, whereby she discovers the preexisting lock:
$ /usr/local/bin/gimp raisin.jpg gimp: error: file is read-only! $ ls -l raisin.jpg -r--r--r-- 1 sally sally 215589 Jun 8 19:23 raisin.jpg $ svn lock raisin.jpg svn: Lock request failed: 423 Locked (http://svn.example.com) $ svn info http://svn.example.com/repos/project/raisin.jpg | grep Lock Lock Token: opaquelocktoken:fc2b4dee-98f9-0310-abf3-653ff3226e6b Lock Owner: harry Lock Created: 2006-06-08 07:29:18 -0500 (Thu, 08 June 2006) Lock Comment (1 line): Making some tweaks. Locking for the next two hours. $
Users and administrators alike are encouraged to attach the
svn:needs-lock
property to any file
that cannot be contextually merged. This is the primary technique for
encouraging good locking habits and preventing wasted effort.
Note that this property is a communication tool that works independently from the locking system. In other words, any file can be locked, whether or not this property is present. And conversely, the presence of this property doesn’t make the repository require a lock when committing.
Unfortunately, the system isn’t flawless. It’s possible that even when a file has the property, the read-only reminder won’t always work. Sometimes applications misbehave and “hijack” the read-only file, silently allowing users to edit and save the file anyway. There’s not much that Subversion can do in this situation—at the end of the day, there’s simply no substitution for good interpersonal communication.[16]