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: ...