| Both sides previous revision Previous revision Next revision | Previous revision |
| versioncontrol:commitmail [2006/09/19 10:10] – NikClayton | versioncontrol:commitmail [2022/10/07 01:43] (current) – Move bakeoff stuff under a single namespace KubilayKocak |
|---|
| ===== 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. |
| |