SVN Lock Communication

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 -u, so she has no idea that Harry has already locked the file. She spends hours edit-
ing 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. Regard-
less, 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 be-
gins. 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.


본 내용은 http://svnbook.red-bean.com/ 에서 제공한 가이드 문서에서 발췌한 내용입니다.

본문 내용에 대한 수정은 없으며, 필요에 의해 구문 강조를 하였습니다.