[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 19:48:23 CEST

On Jul 1, 2006, at 19:13, Marvin D. Toll wrote:

> Erik/Ryan - I'm hearing two different strategies ... and they may
> not be
> mutually exclusive. Looks like I need time to digest this ... see
> inline
> below

I think we're probably talking about the same thing...

>> As a matter of "best practice", both users and administrators are
>> encouraged to attach the svn:needs-lock property to any file which
>> cannot be
>> contextually merged ...
>> To force developers to lock files, use the svn:needs-lock property
> ...
> OK - sounds like we are almost there --- if I presume the "Automatic
> Property Setting" capability can force the "needs-lock" property to
> be set
> as long as one explicitly registers *all* possible artifact
> extensions.

Right. If you want *all* files to have svn:needs-lock, you can use
"*" to match all files regardless of extension.

>> Subversion also provides the auto-props feature, which allows you
>> to create mappings of filename patterns to property names and
>> values. These
>> mappings are made in your runtime configuration area. They again
>> affect adds
>> and imports, and not only can override any default MIME type
>> decision made
>> by Subversion during those operations, they can also set additional
>> Subversion or custom properties, too. For example, you might create a
>> mapping that says that any time you add JPEG files-ones that match
>> the
>> pattern *.jpg-Subversion should automatically set the svn:mime-
>> type property
>> on those files to image/jpeg. Or perhaps any files that match
>> *.cpp should
>> have svn:eol-style set to native, and svn:keywords set to Id. Auto-
>> prop
>> support is perhaps the handiest property related tool in the
>> Subversion
>> toolbox. See the section called "Config" for more about
>> configuring that
>> support.
>> The auto-props section controls the Subversion client's ability to
>> automatically set properties on files when they are added or
>> imported. It
>> contains any number of key-value pairs in the format PATTERN =
>> PROPNAME=PROPVALUE where PATTERN is a file pattern that matches a
>> set of
>> filenames and the rest of the line is the property and its value.
>> Multiple
>> matches on a file will result in multiple propsets for that file;
>> however,
>> there is no guarantee that auto-props will be applied in the order
>> in which
>> they are listed in the config file, so you can't have one rule
>> "override"
>> another. You can find several examples of auto-props usage in the
>> config
>> file. Lastly, don't forget to set enable-auto-props to yes in the
>> miscellany
>> section if you want to enable auto-props.
> Strategy TWO
> It appears Ryan is promoting another (?) strategy - where the
> client code
> has a role in the process.
>> 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.
>> 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.

Well note that auto-props are a client-side thing. There isn't really
any server-side property setting. So if you want a file (or all
files) to get the svn:needs-lock property, the only way it's going to
happen is if the user sets it on the file before committing it. To
make it automatic, the user would set up auto-props in their config
file. But since you can't force a user to use a particular config
file, they might forget, or intentionally not do it. So, if you still
want to enforce that every file in the repository has this property,
you would write and install a pre-commit hook that prevents anyone
from committing a file that doesn't have the property set. If they
try, you would output a helpful error message explaining that the
user should use auto-props to set this on all files, or even direct
them to a URL where they can download a recommended config file.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 1 19:49:36 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.