Description

Lock Communication

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 she's out of date.
Regardless, her changes aren't mergeable with Harry's. One of
these two people has to throw away their 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), then 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 running
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, then 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 pre-existing lock:

Tip

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.
[17]