On 08/21/2012 11:56 AM, C. Michael Pilato wrote:
On 08/21/2012 02:45 PM, Philip Martin wrote:
Blair Zajac <bl...@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.
True, good point. Moving anything there isn't save. In my setup, we
have symlinks to a common area, which wouldn't break with a rename, but
I would be surprised.
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]").
A missing pre-revprop-change script will warn to users doing a propedit,
which is infrequent. But for a non-ideal hooks, do we warn all
committers? That would be annoying, but probably result in a prompt fix
by the admin ;)
Blair
