| Both sides previous revision Previous revision Next revision | Previous revision |
| versioncontrol:commitmail [2006/09/19 21:29] – typo & fix formatting of the list in Hg section. OllivierRobert | versioncontrol:commitmail [2022/10/07 01:43] (current) – Move bakeoff stuff under a single namespace KubilayKocak |
|---|
| |
| 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. |
| |