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

Re: Post-commit issues using commit-email.pl

From: Jason Forkey <jason_at_forkey.net>
Date: 2007-05-10 16:09:41 CEST

At Thu, 10 May 2007 04:34:48 -0500,
Ryan Schmidt <subversion-2007b@ryandesign.com> wrote:
>
> I find it highly irregular that you're trying to configure commit-
> email.pl by editing its source. Surely that shouldn't be necessary.
> I've never used it, but let me have a quick look.
>
> Ok. First of all, the definition of $svnlook was already correct in
> my version of commit-email.pl, since my package manager took care of
> that for me, since that's one of its jobs (making sure all the parts
> play nicely with one another). Did your package manager not fix this
> properly? If so, please take it up with the developers of your
> package manager. If you did not use a package manager but installed
> the script manually, then yes, you need to fix up that location
> yourself.
>
> Next, I concede that perhaps you need to enable $sendmail (and
> disable $smtp_server) by editing the source. I had to do it too.
> That's unfortunate; you'd think there would be a command-line
> argument or a config file to set that behavior.
>
>
> Now on to the good stuff. Running commit-email.pl without any
> arguments prints out a big fat usage message as follows; please read
> all of it:
>
> -----------------------------------------------------------
> $ perl commit-email.pl
> commit-email.pl: too few arguments.
> usage (commit mode):
> commit-email.pl REPOS REVNUM [[-m regex] [options]
> [email_addr ...]] ...
> usage: (revprop-change mode):
> commit-email.pl --revprop-change REPOS REVNUM USER PROPNAME [-d
> diff_file] \
> [[-m regex] [options] [email_addr ...]] ...
> options are:
> --from email_address Email address for 'From:' (overrides -h)
> -h hostname Hostname to append to author for 'From:'
> -l logfile Append mail contents to this log file
> -m regex Regular expression to match committed path
> -r email_address Email address for 'Reply-To:'
> -s subject_prefix Subject line prefix
> --diff y|n Include diff in message (default: y)
> (applies to commit mode only)
>
> This script supports a single repository with multiple projects,
> where each project receives email only for actions that affect that
> project. A project is identified by using the -m command line
> option with a regular expression argument. If the given revision
> contains modifications to a path that matches the regular
> expression, then the action applies to the project.
>
> Any of the following -h, -l, -r, -s and --diff command line options
> and following email addresses are associated with this project. The
> next -m resets the -h, -l, -r, -s and --diff command line options
> and the list of email addresses.
>
> To support a single project conveniently, the script initializes
> itself with an implicit -m . rule that matches any modifications
> to the repository. Therefore, to use the script for a single-
> project repository, just use the other command line options and
> a list of email addresses on the command line. If you do not want
> a rule that matches the entire repository, then use -m with a
> regular expression before any other command line options or email
> addresses.
>
> 'revprop-change' mode:
> The message will contain a copy of the diff_file if it is provided,
> otherwise a copy of the (assumed to be new) property value.
> -----------------------------------------------------------
>
>
> Let me try some examples: Here's a basic post-commit hook to send an
> email to "all-commits@example.com" from "<username>@example.com" when
> any revision is committed:
>
> -----------------------------------------------------------
> #!/bin/sh
>
> REPOS="$1"
> REV="$2"
>
> COMMIT_EMAIL="/path/to/commit-email.pl"
>
> "$COMMIT_EMAIL" "$REPOS" "$REV" \
> -h example.com \
> all-commits@example.com
> -----------------------------------------------------------
>
>
> Here's a more complicated invocation. It sends email to a
> hypothetical mailing list "foo-commits@example.org" from
> "<username>@example.org" with a reply-to address of another
> hypothetical mailing list "foo-discuss@example.org" if the revision
> changes something under /foo/ in the repository. Diffs are not
> included in the mail. In addition, an email is sent to
> tom@example.net, dick@example.net and harry@example.net from
> "<username>@example.net" if the revision changes something in /tdh/
> in the repository. The subject line of the email is prefixed with the
> string "[tdh]". Diffs are sent with this mail because that's the
> default. Finally, an email with diffs is sent to "all-
> commits@example.com" from "repository@example.com" for every revision.
>
> -----------------------------------------------------------
> "$COMMIT_EMAIL" "$REPOS" "$REV" \
> \
> -m ^/foo/ \
> -r foo-discuss@example.org \
> -h example.org \
> --diff n \
> foo-commits@example.org \
> \
> -m "^/tdh/" \
> -h example.net \
> -s "[tdh]" \
> tom@ryandesign.com \
> dick@ryandesign.com \
> harry@ryandesign.com \
> \
> -m . \
> --from repository@example.com \
> all-commits@example.com
> -----------------------------------------------------------
>
>
> Do you see now? You just provide lots of parameters to the script
> when you invoke it from your hook script.
>
>

I think I now see why no one else reported the problem I first ran in to when
running the script. People are configuring the script to call sendmail
directly, which, of course, should not be necessary. If you do not edit the
script at all and try to run your second example above you will get the error:

commit-email.pl: use of either `-h' or `--from' is mandatory when sending email using direct SMTP.

The problem is the default operation of the script: "To support a single project
conveniently, the script initializes itself with an implicit -m . rule that
matches any modifications to the repository"

This implicit -m rule should disappear for your second example: "If you do not
want a rule that matches the entire repository, then use -m with a regular
expression before any other command line options or email addresses."

The problem is that the implicit rule does not seem to disappear for this case.
That causes an error for people trying to connect directly to the SMTP port
($smtp_server = "127.0.0.1") because in this mode the -h option is required but
is not set up for the implicit rule.

Some examples:
Connecting to SMTP port ($smtp_server = "127.0.0.1"):
"$COMMIT_EMAIL" "$REPOS" "$REV" -h svnserver tom@example.com jerry@example.com
This works.

"$COMMIT_EMAIL" "$REPOS" "$REV" -m "/some/project" -h svnserver tom@example.com jerry@example.com
This fails.

Calling sendmail directly ($sendmail = "/usr/sbin/sendmail"):
"$COMMIT_EMAIL" "$REPOS" "$REV" tom@example.com jerry@example.com
This works.

"$COMMIT_EMAIL" "$REPOS" "$REV" -m "/some/project" tom@example.com jerry@example.com
This works.

It looks like in the sendmail case the implicit rule is still lingering around.
It's just not causing any errors. Connecting to the SMTP port is a better
solution because it allows other mail programs besides sendmail and because it
allows connection to external smtp servers. Because of this, I still recommend
editing the script to change this line

my @project_settings_list = (&new_project);
to
my @project_settings_list = ();

That will remove the implicit rule, which is unecessary anyway. Perhaps this
bug will be fixed in the future, but it is necessary to edit the script now if
you 1. want to connect to the SMTP port to send mail and 2. want to use the -m
command line option.

Also, I recommend changing the defaults for $no_diff_deleted and $no_diff_added
to 1. This will prevent ridiculously long emails from being sent out when a
large group of files is added to a repository.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 10 16:10:06 2007

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.