Sat, 29 Jun 2013 19:11:24 +0200 i18n-el: add missing indention for literal block stable
Martin Geisler <martin@geisler.net> [Sat, 29 Jun 2013 19:11:24 +0200] rev 19344
i18n-el: add missing indention for literal block Thanks to Timeless for flagging this.
Mon, 24 Jun 2013 00:00:53 -0400 i18n-el: remove extra newline stable
timeless@mozdev.org [Mon, 24 Jun 2013 00:00:53 -0400] rev 19343
i18n-el: remove extra newline
Sun, 23 Jun 2013 14:19:37 -0400 i18n-el: remove duplicate paragraphs stable
timeless@mozdev.org [Sun, 23 Jun 2013 14:19:37 -0400] rev 19342
i18n-el: remove duplicate paragraphs They were added in the conversion done in 8ef2cd109dc6.
Mon, 24 Jun 2013 00:11:28 -0400 i18n-zh_CN: remove duplicate paragraphs stable
timeless@mozdev.org [Mon, 24 Jun 2013 00:11:28 -0400] rev 19341
i18n-zh_CN: remove duplicate paragraphs They are added in the automatic conversion in e5b7841e0008.
Sun, 23 Jun 2013 18:30:10 -0400 i18n-zh_CN: add missing literal blocks stable
timeless@mozdev.org [Sun, 23 Jun 2013 18:30:10 -0400] rev 19340
i18n-zh_CN: add missing literal blocks
Sun, 23 Jun 2013 18:27:17 -0400 i18n-zh_CN: remove duplicate paragraphs stable
timeless@mozdev.org [Sun, 23 Jun 2013 18:27:17 -0400] rev 19339
i18n-zh_CN: remove duplicate paragraphs
Sun, 23 Jun 2013 18:10:02 -0400 i18n-ru: spell "ElementTree" correctly stable
timeless@mozdev.org [Sun, 23 Jun 2013 18:10:02 -0400] rev 19338
i18n-ru: spell "ElementTree" correctly
Sun, 23 Jun 2013 17:40:03 -0400 i18n-ru: fix translated config section stable
timeless@mozdev.org [Sun, 23 Jun 2013 17:40:03 -0400] rev 19337
i18n-ru: fix translated config section
Sun, 30 Jun 2013 14:56:04 -0500 merge with crew
Matt Mackall <mpm@selenic.com> [Sun, 30 Jun 2013 14:56:04 -0500] rev 19336
merge with crew
Wed, 26 Jun 2013 23:12:55 +0200 tests: simplify and document the sorting of pyflake messages
Simon Heimberg <simohe@besonet.ch> [Wed, 26 Jun 2013 23:12:55 +0200] rev 19335
tests: simplify and document the sorting of pyflake messages The pyflake messages are simply ordered by message type, path, line no (and message text). The message type is taken from the order of the filters. The previous ordering looks complicated and illogically. It was the following order (r'\3:\5:\4:\1:\2:' + line): message (\3 and \5) var name (\4) path (\1) line no (\2) line reference Ordering by var name before path looks illogically for me.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip