Correcting a studid mistake:
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.
> 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>
"<stdout>" should read "<stderr>"
> - 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
Sorry
Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Apr 19 13:30:59 2005