On 08/21/2012 02:55 PM, Mark Phippard wrote:
> On Tue, Aug 21, 2012 at 2:38 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> On 08/21/2012 02:29 PM, Blair Zajac 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.
>>
>> Cool. Will make that my next set of changes, then. Thanks for the feedback.
>
> Who besides a SVN developer would know that pre/post create-txn comes
> before pre-commit? I do not see how these names are an improvement.
> I also do not think start-commit, pre-commit were all that confusing
> to end users. The confusing part is always just understanding what
> you can do in the hooks.
Hook authorship falls to admins, not mere users. And I think it is fair to
say that we expect admins to understand the notion of commit transactions as
"revisions-to-be". In fact, we expose this nomenclature readily through the
'svnlook -t TXN_NAME ...' interfaces. You pretty much can't write a
pre-commit hook script without "getting" the concept of these 'txn' things.
> Did you ever say why you ruled out your earlier idea of simply moving
> where the start-commit hook was called to later in the process where
> more information would be available?
>
> If we have a new hook, I do not have an obvious idea as to better new
> name. Maybe init-commit just so that the link to the commit process
> is being maintained. Then we would have to document the order is
> start > init > pre > post
>
> It seems like moving the start-commit hook would be easiest option and
> I do not immediately see how it would break existing hooks. So I do
> not see the downside to that option.
One downside of changing the behavior of the start-commit hook is that it
will no longer be useful for making a repository effectively read-only in
the way that it is today (in concert with restrictive pre-revprop-change,
pre-lock, and pre-unlock hooks).
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2012-08-21 21:01:13 CEST