[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: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 21 Aug 2012 15:00:39 -0400

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

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