FixMe or "waiting for #781…"

Commit Log Messages As They Should Have Been

• r2160

  Follow-up to r2144: new ticket messages were not HTML escaped
  (closes #1995)
  

• r2646

  vc-refactoring: merge from log:trunk@2622:2645, last one compatible with TracMercurial v0.1
  

• r2743: s/Taggning/Tagging/
• r3267: actually, r3177 and not r3176 was missing (the eternal question "svn merge -rX:Y ... is X part of the merge or not?")
• r3318: … With [3316], With [3317],
• r3434: … behavior which was broken by r3371 not r3771
• r3597: … [3595:3596] instead of [3495:3496] … (that was because of related ticket #3495, I guess)
• About r3616: Actually, my assumption that it was the presence of a dict within the dict that changed the order of items was wrong: it's most probably simply because it's the sequence of insertion of the keys inside the dict which determines the subsequent order of the items().
• r3929: fixes an issue introduced by r3921, not r3920…
• r4818: …follow-up to r4813
• r4933: s/self.id/self.parent.id/
• r5124: was a follow-up to r4534 not r4543 …
• r5153: should be "VcRefactoring/Controller: Merged revisions [5146-5152/trunk] via svnmerge"
• r5598 and r6600 were all mixed up…
  • r5598 needs the changeset.py and changeset.html changes from r6600
  • r6600 was really a one liner in query_results.html
  • I don't know how I managed to do this :-(
• r7346: message should have been: In TracReports, not all user parameters from the request were propagated to the report page links (closes #7424)
• r7353: copy/pasted the wrong hash for mercurial changeset 6749, should have been 6749:51b0e799352f (the link nevertheless work because only the first number is used in the url)
• r7610: stupid typo: s/will known/will know/

---

• r10357: s/9920/9220/

Note that the long gap 7600/10300 corresponds to the period we were fixing the commit messages directly in Subversion, change reflected in Trac with the post-revprop-change hook. Now that we immediately mirror the Subversion repository to both Mercurial and Git, there's no point in editing the message in the repository itself, but we could revive the idea of storing corrections in Trac, as proposed by #781.