On Tue, Aug 21, 2012 at 3:00 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> 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.
I am simply pointing out that anyone who believes these new names
makes things crystal clear are too close to the underlying code. In
particular as an admin and hook author I would have no reason to
expect that a post-create-txn hook only contains a small subset of the
data that will ultimately go into the transaction. I imagine this is
why you initially were leaning towards "init-txn". I think of
creating the txn as also populating things like the list of files and
likely the data as well. AFAIK, you are proposing to call the hook
after only the basics of the txn have been established.
I am not proposing another hook with this additional data either.
Just trying to inject some skepticism into how clear these names
really make things. In an ideal world, I would have a better name to
propose. I realize that.
I am also not crazy about introducing a bunch of new hooks that are
all more or less what the original start-commit hook was doing.
> 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).
Fair enough.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2012-08-21 21:08:28 CEST