Description

E-mail messages to one or more addresses should be generated when a change is committed. Format of e-mail may change (e.g., doc committer committing to src tree)

Current Implementation

A rather complex set of Perl scripts is used to generate commit mails. It tries to regroup similar commits in order to generate one mail even for big commits (as there is no atomic feature in CVS).

SVN Implementation

Subversion does not support commit mail directly. However, a hook script which is automatically run after a commit succeeds (hooks/post-commit) is passed sufficient information to generate a commit e-mail.

We could develop our own hook script, or use one of the many that are already available, either in the Subversion contrib directory, or on other sites.

My personal preference is for SVN::Notify. There is more documentation at http://search.cpan.org/~dwheeler/SVN-Notify-2.63/lib/SVN/Notify.pm. This is a very flexible tool that allows us to control the format of notification messages and where they go.

SVN::Notify does not directly support our current warnings (e.g., that a doc/ committer has committed to the src/ tree). However, the code is OO, and it should be possible to write a subclass that amends the default behaviour to support this. There are already several succesful subclasses of SVN::Notify that add additional behaviour (e.g., generating reports in HTML instead of plain text).

Hg Implementation

There are two hooks in Hg that can be used for commit mail notifications through the notify extension (or plugin.

  1. for each individual changeset, we can have a mail delivered
  2. for each merge (multiple changesets commit), we can have a different mail sent.

Several parameters can be set, including the max size of included diffs (if requested), a style for templating and so on.

However, an alternative to this would be through the use of a Patch_Queue_Manager that would enables us to streamlise the commits to the reference tree and apply all matter of policies needed (during freezes and slushes for example).

Git Implementation

The update hook allows for actions when a head is updated. This is typically used for commit mail. It is given the head name being updated, and the old and new sha1 hashes. This could be used to filter on the committed-by fields of the log that you can get from those 2 hashes, and the results used to note in the mail when a change is pushed that affects a repository other than what that committer has full access to.

However, this could get odd. Say some ports committer says "I've got this interesting set of code for src at the following refspec, someone want to review and maybe push it?" A src committer pulls that code down, reviews it, decides it's good, and pushes it. The author and committer information from the ports committer is retained in that history, so the update hook decides that it deserves annotation, but the push was by a full-rights src committer. We could probably filter on $USER vs. rights rather than committed-by vs. rights, but it's not clear to me which behavior would really be desired here.

Monotone Implementation

Supported (also see monotone:FeatureCommitMail)

Monotone supports this and many similar kinds of actions and triggers via hooks.

There is a hook that can be invoked on commit, but this will run on the individual developer's machine where the commit is done offline. It would be more usual to generate these messages instead when the committed revisions arrive via netsync at a convenient public server (see monotone:MasterRepository) with the appropriate email infrastructure. Monotone also includes a hook implementation for emitting events to CIA, from where the notifications can also be sent to IRC channels and RSS feeds.

VersionControl/CommitMail (last edited 2022-10-07T01:43:14+0000 by KubilayKocak)