> Different people might have different reasons. Perhaps nobody has
> explained the exact problem. Perhaps nobody has put forward a
> convincing argument as to why it is necessary. Or perhaps the
> implementation costs outweigh the benefits.
There seems to be a problem with svnlook when invoked inside a
transaction from a hook, during large commits
(http://bugzilla.mkgnu.net/show_bug.cgi?id=723). You will probably be
hearing from us soon on this, as we are trying to debug it. Certainly,
the team that developed the integration hooks can always go in and add
additional debug statements redirected to a file, rather than stdout.
But a developer (SVN+Scmbug customer), who has no idea how the
integration hooks work, or where they are installed, would only be able
to determine what went wrong if the hook itself was providing during
it's execution some output to stdout.
> That sounds like you assume Kristis Makris is talking about
> post-commit output, but I'm not so sure. It could be a request to
Exactly. It is the pre-commit hook I'm talking about.
> make a hooks stdout output get back to the client. Or it could be a
> request to make a hooks stderr output get back to the client even when
> the hook succeeds. It could even be a request that the hooks output
> should get back to the client while the hook is running.
Yes. Yes! It is a request to make a hooks stdout output back to the
client, **while the hook is executing**. The stderr "sounds like" it
should also be propagated to the client. In the particular bug
referenced above, we are observing a deadlock, and there is no output
from the hook yet, so we could determine where exactly in the hook the
deadlock occurs.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 29 23:46:53 2006