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
-----Original Message-----
Subject: Re: Pessimistic Locking
[MDT] Strategy ONE
[Excerpt] 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 ...
[Excerpt] To force developers to lock files, use the svn:needs-lock property
...
[MDT] 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.
[Excerpt] 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.
[Excerpt] 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.
[MDT] Strategy TWO
It appears Ryan is promoting another (?) strategy - where the client code
has a role in the process.
[Excerpt]
> 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.
---------------------------------------------------------------------
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:14:39 2006