11.07.2015 Views

Version Control with Subversion - Login

Version Control with Subversion - Login

Version Control with Subversion - Login

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Advanced Topicsrampant and the whole point of locking is defeated. The other side argues that locksare first and foremost a communication tool. If users are constantly breaking eachother's locks, it represents a cultural failure <strong>with</strong>in the team and the problem falls outsidethe scope of software enforcement.<strong>Subversion</strong> defaults to the “softer” approach, but still allows administrators to createstricter enforcement policies through the use of hook scripts. In particular, the prelockand pre-unlock hooks allow administrators to decide when lock creation andlock releases are allowed to happen. Depending on whether a lock already exists,these two hooks can decide whether to allow a certain user to break or steal a lock.The post-lock and post-unlock hooks are also available, and can be used tosend email after locking actions. To learn more about repository hooks, see the sectioncalled “Implementing Repository Hooks”.Lock CommunicationWe've seen how svn lock and svn unlock can be used to create, release, break, andsteal locks. This satisfies the goal of serializing commit access to a file. But what about thelarger 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 spendshours editing the file, and when she tries to commit her change, she discovers that eitherthe file is locked or that she's out of date. Regardless, her changes aren't mergeable <strong>with</strong>Harry's. One of these two people has to throw away his or her work, and a lot of time hasbeen wasted.<strong>Subversion</strong>'s solution to this problem is to provide a mechanism to remind users that a fileought 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),<strong>Subversion</strong> will try to use filesystem-level permissions to make the file readonly—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, thefile becomes read-only again.The theory, then, is that if the image file has this property attached, Sally would immediatelynotice something is strange when she opens the file for editing: many applicationsalert users immediately when a read-only file is opened for editing, and nearly all wouldprevent 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.jpggimp: 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.jpgsvn: Lock request failed: 423 Locked (http://svn.example.com)$ svn info http://svn.example.com/repos/project/raisin.jpg | grep LockLock Token: opaquelocktoken:fc2b4dee-98f9-0310-abf3-653ff3226e6bLock Owner: harryLock 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.$69

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!