William Nagel wrote:
> It would be interesting to allow hook scripts to communicate
> bidirectionally with the client, requesting further input when they need
> it. That would be a hard feature to get right, though, and it would
> require support on both the server and the client.
>
> For now, it should be noted that you can perform a limited amount of
> communication back to the user from your hook scripts. Anything that
> you write to standard error will be sent back to the client and
> displayed.
... but ONLY if the hook returns Failure (that is, return code is different
from 0) and thus reject the commit.
That also means that a "real communication" between server and client does
not take place - it is more like:
- the hook can write an error message (which may be build up from several
pieces of text, not neccesarily all in one go) to <stdout>
- if the hook returns 1, everything written to <stderr> up to that point
is transferred to the client and shown there.
(If the hook returns 0 and thereby accepts the commit, everything the hook
has written to <stderr> is thrown away.)
By the way, because the error message must be written to *<stderr>*, 'rbash'
cannot be used to operate a hook script, a full-featured 'bash' or a different
shell is needed. 'rbash' cannot do redirections, for security reasons.
> So if you want to require a defect ID, you can parse the log
> message to look for one, and if it's not there cancel the commit with an
> error message to the user telling them that they need to add a defect ID
> to their log message and recommit.
>
> -Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 19 12:23:13 2005