[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Pessimistic Locking

From: Ryan Schmidt <subversion-2006q2_at_ryandesign.com>
Date: 2006-07-01 18:43:37 CEST

On Jul 1, 2006, at 18:10, Marvin D. Toll wrote:

>>> Context: I'm a J2EE consultant currently working at a Fortune
>>> 300 company
>>> using ClearCase (with pessimistic locking) for Java development
>>> artifacts.
>>> Question: Can Subversion be configured to (reliably) "force"
>>> pessimistic
>>> locks? (Hook Scripts?)
>> Well, that's not enough context: what's a pessimistic lock?
> See http://www.agiledata.org/essays/concurrencyControl.html for a
> definition within a database context. Traditionally, mainframe
> version
> control systems and more recent (last 10 years or so) vendor supported
> client/server tools like ClearCase and PVCS default to pessimistic
> locking
> of artifacts "checked-out" for modification.
>> Subversion supports locking through its 'svn lock'/'svn unlock'
>> commands.
> The *key* word of my inquiry was "force". I understand the default
> implementation of Subversion (for example as implemented by
> SourceForge) to
> support "optional" locking - however, my world is not one in which
> such
> options are bestowed to commodity developers - onshore or offshore.
>> See for more info:
>> http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html
> The "Harry" example leaves it to the individual developer to make a
> decision often made corporate-wide at large companies. Excerpt:
>> "An example is in order, to demonstrate. Let's say that Harry has
>> decided to
>> change a JPEG image. To prevent other people from committing
>> changes to the
>> file, he locks the file in the repository using the svn lock
>> command ..."

Yes, I think it is possible to make Subversion force the locking
model you're after. On that same page, you should also see the block
"Locking Policies" which says:

> Subversion defaults to the “softer” approach, but still allows
> administrators to create stricter enforcement policies through the
> use of hook scripts. In particular, the pre-lock and pre-unlock
> hooks allow administrators to decide when lock creation and lock
> releases are allowed to happen.

By default, anyone can break a lock on a file, but if you want to
prevent that, you can write a pre-unlock hook that allows only, say,
the person who locked the file to unlock it.

Under the next section, "Lock Communication," the svn:needs-lock
property is described, which, when applied to a file, causes that
file to be read-only in your working copy until you lock it. This
prevents someone from wasting time editing a file which someone else
may already have locked. You can ask your users to configure
automatic properties in their Subversion client, so that each file
gets the svn:needs-lock property. You can write a pre-commit hook
that prevents committing any file that does not have this property.

After those two changes, you would now have a Subversion repository
where every file must be locked before you can edit it, and nobody
can break anyone else's lock.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 1 18:44:51 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.