[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Mark Phippard <markphip_at_gmail.com>
Date: Tue, 21 Aug 2012 14:55:40 -0400

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.

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.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2012-08-21 20:56:12 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.