| OLD | NEW | 
|---|
| (Empty) |  | 
|  | 1 # Mercurial hooks | 
|  | 2 | 
|  | 3 `sitescripts/hg` contains Mercurial hooks for integration with other components | 
|  | 4 of our infrastructure. | 
|  | 5 | 
|  | 6 ## IRC integration | 
|  | 7 | 
|  | 8 `irchook.py` contains a commit hook that posts the information about new pushed | 
|  | 9 commits to an IRC channel. | 
|  | 10 | 
|  | 11 ## Trac integration | 
|  | 12 | 
|  | 13 `update_issues.py` contains two hooks: `changegroup_hook` and `pushkey_hook`. | 
|  | 14 They will recognise issue references in commit messages and update referenced | 
|  | 15 issues in Adblock Plus issue tracker. | 
|  | 16 | 
|  | 17 The format of the commit messages is "ISSUE-REFERENCE - MESSAGE" | 
|  | 18 where ISSUE-REFERENCE is one of "Noissue", "Issue NUMBER" or "Fixes NUMBER". | 
|  | 19 Several "Issue" and "Fixes" references separated by commas can be present | 
|  | 20 in the same commit message (for example: "Issue 1, Fixes 2 - Two issues"). | 
|  | 21 Such commit will affect all the referenced issues. | 
|  | 22 | 
|  | 23 * `changegroup_hook` will post a comment with the link to the commit into the | 
|  | 24   issue if the issue is referenced from the commit message. | 
|  | 25 * `pushkey_hook` will close the issues and assign milestones to them (based | 
|  | 26   on their module) when `master` bookmark passes over the commits that fix | 
|  | 27   them. It will not assign a milestone if the issue already has one. | 
|  | 28 | 
|  | 29 ### Configuring the repository | 
|  | 30 | 
|  | 31 `changegroup_hook` should be installed as `changegroup` or | 
|  | 32 `pretxnchangegroup` hook. `pushkey_hook` should be installed as | 
|  | 33 `pushkey` or `prepushkey` hook. For example (in `.hg/hgrc`): | 
|  | 34 | 
|  | 35     [hooks] | 
|  | 36     pretxnchangegroup = python:.../update_issues.py:changegroup_hook | 
|  | 37     pushkey = python:.../update_issues.py:pushkey_hook | 
|  | 38 | 
|  | 39 ### Configuring the hooks | 
|  | 40 | 
|  | 41 The hooks are configured via `sitescripts.ini` in `hg` and | 
|  | 42 `hg_module_milestones` sections. For example: | 
|  | 43 | 
|  | 44     [hg] | 
|  | 45     trac_xmlrpc_url=https://abpbot:abpbot@issues.adblockplus.org/login/xmlrpc | 
|  | 46     issue_url_template=https://issues.adblockplus.org/ticket/{id} | 
|  | 47 | 
|  | 48     [hg_module_milestones] | 
|  | 49     platform=adblock-plus(-[\d\.]+)?-for-chrome-opera-safari(-next)? | 
|  | 50     Adblock-Plus-for-Firefox=adblock-plus(-[\d\.]+)?-for-firefox(-next)? | 
|  | 51 | 
|  | 52 `hg.track_xmlrpc_url` key from is used to determine the address of XMLRPC | 
|  | 53 interface of Trac and `hg.issue_url_template` as a template for producing links | 
|  | 54 to the referenced issues that are displayed in the log. | 
|  | 55 | 
|  | 56 The keys of the `hg_module_milestones` section are module names and the values | 
|  | 57 are corresponding milestone regular expressions (they are matched | 
|  | 58 case-insensitively). The first open milestone that matches the regular | 
|  | 59 expression of issue's module will be assigned to the issue when the `master` | 
|  | 60 bookmark passes a commit that fixes it. | 
|  | 61 | 
|  | 62 ### Master bookmark | 
|  | 63 | 
|  | 64 What exactly does it mean when we say _`master` bookmark is passing a commit_? | 
|  | 65 The idea is that if the `master` bookmark _passed_ a commit we will have | 
|  | 66 those changes in our working copy when we do `hg checkout master`. | 
|  | 67 | 
|  | 68 Let's first look at a simple case, linear commit history like this: | 
|  | 69 | 
|  | 70     one <- two <- three | 
|  | 71 | 
|  | 72 Here `one` is a parent commit of `two` and `two` is a parent of `three`. If | 
|  | 73 the `master` bookmark was on `one` and then moved to `three`, we say that it | 
|  | 74 passed `two` and `three`. This would happen naturally if we clone the | 
|  | 75 repository that contains `one` with the `master` bookmark pointing to it, | 
|  | 76 check out `master`, author two commits and then push them. | 
|  | 77 | 
|  | 78 A somewhat similar thing happens when we have branches: | 
|  | 79 | 
|  | 80     one <---- two <---- three | 
|  | 81          \            / | 
|  | 82           \-- dos <--/ | 
|  | 83 | 
|  | 84 Here `one` is a parent commit of `two` and `dos` and they are both parents | 
|  | 85 of `three`. If the `master` bookmark was on `two` and now is on `three`, | 
|  | 86 we say that it passed `three` and `dos`. What happened here is that by `three` | 
|  | 87 we've merged a branch containing `dos` into the master branch that was going | 
|  | 88 through `one` and `two`. | 
| OLD | NEW | 
|---|