You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Marvin D. Toll" <Ma...@gtcGroup.com> on 2006/07/01 13:34:55 UTC
Pessimistic Locking
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?)
(Note: Please skip any dialog around optional locking and/or philosophical
assertions for/against optimistic locking.)
Thanks,
Marvin
---------------------------------------------------------
| USA Cell: 248.866.4897 (free incoming)
| Message: <ma...@messaging.nextel.com>
2488664897@messaging.nextel.com
| Email: <ma...@gtcGroup.com> MarvinToll@gtcGroup.com
| Web: <http://www.gtcGroup.com> http://www.gtcGroup.com
---------------------------------------------------------
Re: Pessimistic Locking
Posted by David James <dj...@collab.net>.
On 7/1/06, Marvin D. Toll <Ma...@gtcgroup.com> wrote:
> Subversion supports locking through its 'svn lock'/'svn unlock' commands.
>
> [MDT] 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.
> [...]
> [MDT] 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 ..."
To force developers to lock files, use the svn:needs-lock property.
This property is usually intended to be used on files which cannot be
merged automatically (e.g. JPEG files).
http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html#svn.advanced.locking.lock-communication
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Pessimistic Locking
Posted by "Marvin D. Toll" <Ma...@gtcGroup.com>.
Ryan/Erik,
Thank you! This gives me plenty to get started with.
_Marvin
---------------------------------------------------------
| USA Cell: 248.866.4897 (free incoming)
| Message: 2488664897@messaging.nextel.com
| Email: MarvinToll@gtcGroup.com
| Web: http://www.gtcGroup.com
---------------------------------------------------------
-----Original Message-----
From: Ryan Schmidt [mailto:subversion-2006q2@ryandesign.com]
Sent: Saturday, July 01, 2006 1:48 PM
To: MarvinToll@gtcGroup.com
Cc: 'Erik Huelsmann'; users@subversion.tigris.org
Subject: Re: Pessimistic Locking
> "Automatic Property Setting" capability can force the "needs-lock"
property to be set ...
Right. If you want *all* files to have svn:needs-lock, you can use
"*" to match all files regardless of extension.
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
Re: Pessimistic Locking
Posted by Ryan Schmidt <su...@ryandesign.com>.
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
RE: Pessimistic Locking
Posted by "Marvin D. Toll" <Ma...@gtcGroup.com>.
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
Re: Pessimistic Locking
Posted by Ryan Schmidt <su...@ryandesign.com>.
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
RE: Pessimistic Locking
Posted by "Marvin D. Toll" <Ma...@gtcGroup.com>.
Thanks Erik - inline comments below ...
-----Original Message-----
From: Erik Huelsmann [mailto:ehuels@gmail.com]
Sent: Saturday, July 01, 2006 11:40 AM
Subject: Re: Pessimistic Locking
> 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?
[MDT] 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.
[MDT] 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
[MDT] 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 ..."
HTH,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Pessimistic Locking
Posted by Erik Huelsmann <eh...@gmail.com>.
> 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?
Subversion supports locking through its 'svn lock'/'svn unlock' commands.
See for more info:
http://svnbook.red-bean.com/nightly/en/svn.advanced.props.html#svn.advanced.props.special.needs-lock
and
http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html
HTH,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org