On Jan 3, 2006, at 21:58, K Y wrote:
> Stefan Schwarzbach <Schwarzbach@SilentDreams.de> wrote:
>
>> I use the pre-commit hook also to do some checks, f.e. to check if
>> the
>> changelog text is empty or there is a case sense conflict. If
>> something
>> with the commit went wrong due to these checks, I write an error
>> message
>> to stderr and exit the hook script with != 0. The client who tried to
>> commit his changes will get the error message I wrote to stderr as
>> reply
>> to his commit trial.
>
> Exactly. If you perform these tests in the post-commit hook, the
> commit of the files has completed - and then you are trying to also
> commit the logs afterwords (i think i understood your scenario
> correctly).
>
> With a pre-commit hook - you can check what you need - run your
> test shells and commit all of the changes as well as the test log
> files at once - if successful.
It doesn't really work that way with a pre-commit hook though. You
cannot modify the transaction that's in progress; doing so would
break the user's working copy. Instead, regardless of whether you're
doing it in a pre- or a post-commit hook, your hook must maintain its
own working copy, apply the desired changes, and commit it as a
second revision. You should also clearly engineer your hook so that
it does not react to the automatic commit that you're doing, lest you
cause an endless loop.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 4 18:37:13 2006