[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Newbie /etc/subversion question

From: Dirk Schenkewitz <schenkewitz_at_docomolab-euro.com>
Date: 2005-04-19 12:19:13 CEST

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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.