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

Re: Why not just enforce auto-props with a hook script that sets the right properties

From: Ryan Schmidt <subversion-2008b_at_ryandesign.com>
Date: Tue, 10 Jun 2008 17:03:53 -0500

On Jun 10, 2008, at 16:13, Mark E. Hamilton wrote:

> Peter Kahn wrote:
>> Is there a reason why I shouldn't take check-mime-type.pl a step
>> further and have my hook script set properties on newly added
>> files according to a repository wide policy?
> From the book :http://svnbook.red-bean.com/en/1.4/
> svn.reposadmin.create.html#svn.reposadmin.create.hooks
> While hook scripts can do almost anything, there is one dimension
> in which hook script authors should show restraint: do not modify
> a commit transaction using hook scripts. While it might be tempting
> to use hook scripts to automatically correct errors or shortcomings
> or policy violations present in the files being committed, doing so
> can cause problems. Subversion keeps client-side caches of certain
> bits of repository data, and if you change a commit transaction in
> this way, those caches become undetectably stale. This
> inconsistency can lead to surprising and unexpected behavior.
> Instead of modifying the transaction, you should simply validate
> the transaction in the pre-commit hook and reject the commit if it
> does not meet the desired requirements. As a bonus, your users will
> learn the value of careful, compliance-minded work habits.

Yes, but Peter wasn't suggesting modifying the transaction. He was
suggesting committing a second revision immediately following the
first to correct errors in the first. That can be made to work.
Though as Peter realized, it may be better to teach a man to fish.

To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-06-11 00:04:28 CEST

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.