Re: svn commit: r1375675 - in /subversion/trunk/subversion: include/svn_repos.h libsvn_repos/fs-wrap.c libsvn_repos/hooks.c libsvn_repos/repos.c libsvn_repos/repos.h tests/cmdline/commit_tests.py tests/cmdline/svntest/actions.py

On 08/21/2012 02:45 PM, Philip Martin wrote:
> Blair Zajac <blair_at_orcaware.com> writes:
>
>> On 08/21/2012 11:09 AM, C. Michael Pilato wrote:
>>>
>>> I actually considered using "post-create-txn" and renaming "start-commit" to
>>> "pre-create-txn" (with code to run "start-commit" iff not "pre-create-txn"
>>> hook exists, for compat purposes).
>>
>> +1. I always have to remember which comes first, start-commit or
>> pre-commit, so this renaming helps.
>
> Suppose both pre-create-txn and start-commit exist. Is it an error?
> If not which one is run?
>
> We have already bumped the FSFS format in 1.8 but we have not yet bumped
> the repos format. Perhaps we could bump and have an upgrade that
> renames the hook?

Are we comfortable with renaming the hook, which -- strictly speaking -- is
user-managed data, not Subversion managed data? What if the hook itself is
kept under version control (which is pretty common)? I lean against doing
so. And because no change of administrative behavior is required (we'll
still happily run "start-commit" if there's no "pre-txn-create"), I see no
need for the format bump.

As to whether to flag an error if both "start-commit" and "pre-txn-create"
exist: this makes sense. I see value in warning *someone* that the
repository configuration is non-ideal, similarly to the error we return from
a missing pre-revprop-change hook script ("ask the administrator to [fix
this problem]").

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development