| Both sides previous revision Previous revision Next revision | Previous revision |
| versioncontrol:commitmail [2006/09/19 08:02] – Add Hg notify extention OllivierRobert | versioncontrol:commitmail [2022/10/07 01:43] (current) – Move bakeoff stuff under a single namespace KubilayKocak |
|---|
| ===== Description ===== | ===== 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) | 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) |
| |
| |
| ===== SVN Implementation ===== | ===== 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 ===== | ===== Hg Implementation ===== |
| |
| There are two hooks in Hg that can be used for commit mail notifications through the //notify// extention (or plugin. | 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 | - for each individual changeset, we can have a mail delivered |
| 2. for each merge (multiple changesets commit), we can have a different mail sent. | - 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 | Several parameters can be set, including the max size of included diffs (if |
| |
| However, an alternative to this would be through the use of a | 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 | [[/Patch_Queue_Manager|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 | tree and apply all matter of policies needed (during freezes and slushes for |
| example). | example). |
| |
| 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. | 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 [[http://venge.net/monotone/wiki/FeatureCommitMail|monotone:FeatureCommitMail]]) |
| | |
| | [[/Monotone|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 [[http://venge.net/monotone/wiki/MasterRepository|monotone:MasterRepository]]) with the appropriate email infrastructure. Monotone also includes a hook implementation for emitting events to [[http://cia.navi.cx/stats/project/monotone|CIA]], from where the notifications can also be sent to IRC channels and RSS feeds. |
| |