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