Thanks Julian. I slept on this for a while.
On Thu, 2006-03-30 at 00:00 +0100, Julian Foad wrote:
> I have not seen any satisfactory reasons stated for why the output should be
> reported, and we do not implement any features without good reasons. The hooks
> script feature exists to serve certain purposes, and reporting arbitrary
> messages to the client during the operation is not one of its purposes. (On
> the other hand, reporting an error message when there is an error is a standard
> facility within Subversion.) The statement that "I want to see stdout from my
> hook script" is not enough.
I was convinced that this is a valid response to give to users. That
Subversion chooses not to report the output from hooks, and that a
system administrator is expected to debug them if they are broken. I
suppose the official Subversion response to the question "How are you
planning to report feedback on the status of hooks *while they are
executing*" is "We won't".
I'm not sure I can accept that.
What I'm observing now is users asking the system administrator to check
whether the hooks are working, without them being able to confirm that
they are working. For example, some users are not even aware whether any
hooks are installed, or whether they were installed and are at least
executing (or deadlocking), since they never see any output from them.
This takes up the sysadmin's time to debug the installation of the
users. When sysadmin support is only available through email, or if the
team that developed the hooks is not the sysadmin or part of the users,
nailing down problems becomes more difficult.
> If somebody were to demonstrate why and how receiving the output makes a
> substantial contribution to the usefulness of hook scripts in general, such
> that the benefit to the Subversion community as a whole outweighs the increase
> in complexity of the system, then we would be happy for somebody to do it.
I'm not sure if this is enough to outweight the increase in complexity
of the system. I have only observed that supporting through email users
of Subversion that use 3rd-part hooks is becoming difficult, so you may
decide against this feature.
> It is important to realise that making Subversion report the standard output
> from hook scripts is not "just like reporting standard error, except it's
> stream number 1 instead of 2". On the contrary, it would involve a completely
> new aspect to the concept of what executing a "commit" operation involves:
> there would now be an extra data stream coming back. It is not just the
> Subversion command-line client "svn" that performs commits and would have to be
> upgraded to handle this, but there are also several GUI clients and potentially
> some DAV/delta-V clients (and those operate to an external standard which
> probably does not support such a data stream).
I understand this. I believe it is equally important to realize that
such a possible need may be a sign that an external standard should be
extended to support such a data stream.
> > If one is importing 4000 files, and they have to wait for the hooks to
> > execute, they have no idea if Subversion deadlocked or whether the hook
> > is really executing (or access to the bugtracker for integration is
> > commencing).
>
> That problem is only loosely connected with making stdout from hook scripts
> visible. Simply ensuring that the output is reported is neither necessary
> (other reporting mechanisms could do it) nor sufficient (for one thing, the
> data stream would need to be "flushed" at sufficiently small intervals) to
> solve that problem.
I understand the "not sufficient" argument. It will certainly need
special logic. For a while I thought I was clear on the "neither
necessary" argument too. The hook output could be written on a file, and
a sysadmin could inspect that file. But the following occured to me: If
hooks are executed on the repository in a remote server, and a client
commits a changeset, thus executing the hook, how does one envision the
server informing the client in real-time that the hook is deadlocked or
is currently executing ?
I suppose the response here is "the system administrator" is supposed to
look into that file and figure out what's wrong. The problem in practise
is that quite often one of the users is "officially" the system
administrator, while lacking system administrator expertise to poke
around and resolve problems. Resolving problems becomes the burden of
the entity that developed the hooks. Having the output from the hooks
visible while executing helps resolve problems.
Moreover, suppose a hook executed correctly (or in part) and is supposed
to report back informational messages (not errors) on the actions the
hook was able to accomplish. Should those be reported on "stderr" even
though the hook finished sucessfully with a non-zero exit code ?
Another comment on "neither necessary". If all hooks have to develop
their own reporting mechanism, such as writing the hook messages to a
file, that places a huge burden on all hook-writers. Is that perhaps
reason to uniformly provide reporting for all successful hooks ? I have
to argue that reporting "stdout" seems to be the standard on connecting
output between programs. For example, a GUI Subversion client could use
that output for general error reporting, rather than be aware of other
reporting mechanisms each hook may implement separately.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 15 00:08:54 2006