On Apr 19, 2005, at 5:19 AM, Dirk Schenkewitz wrote:
> 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.
My bad. I forgot that it was only sent back if the script failed.
So was there a specific rationale behind only allowing the hook script
to communicate back on an error, or was that a design tradeoff because
it was easier to only send things back on a failure? It seems to me
that there are a lot of times when it would be useful to send back
information about a successful commit. For example, if an issue in the
issue tracker is closed as a result of the commit, it might be handy to
return a URL to the closed issue, for sanity check purposes.
-Bill
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 19 17:32:23 2005