Tue, 19 Jan 2016 06:00:30 +0100 mq: refactor makepatchname into class method stable
Mads Kiilerich <madski@unity3d.com> [Tue, 19 Jan 2016 06:00:30 +0100] rev 27918
mq: refactor makepatchname into class method
Wed, 20 Jan 2016 13:43:01 -0800 repoview: fix corrupted hiddencache crash Mercurial (issue5042) stable
Laurent Charignon <lcharignon@fb.com> [Wed, 20 Jan 2016 13:43:01 -0800] rev 27917
repoview: fix corrupted hiddencache crash Mercurial (issue5042) Before this patch if the hiddencache existed but was empty, it would crash mercurial. This patch adds exception handling when reading the hiddencache to avoid the issue. When encountering a corrupted cache file we print a devel warning. There would be no point in issuing a normal warning as the user wouldn't be able to do anything about the situation. The warning looks like: devel-warn: corrupted hidden cache, removing it at: /path/to/repoview.py
Wed, 20 Jan 2016 13:40:59 -0800 repoview: add missing newline character in debug prints stable
Laurent Charignon <lcharignon@fb.com> [Wed, 20 Jan 2016 13:40:59 -0800] rev 27916
repoview: add missing newline character in debug prints
Wed, 20 Jan 2016 00:08:00 +0900 commandserver: drop tell() and seek() from channels (issue5049) stable
Yuya Nishihara <yuya@tcha.org> [Wed, 20 Jan 2016 00:08:00 +0900] rev 27915
commandserver: drop tell() and seek() from channels (issue5049) These operations are obviously invalid for file-like channels because they will read or write protocol headers. This patch works around the issue that "hg archive" generates a corrupted zip file on Windows commandserver because of unusable tell() implementation. But the problem still occurs without using a commandserver. $ hg archive -R not-small-repo -t zip - | cat > invalid.zip So, this patch cannot fix the issue5049 completely.
Wed, 20 Jan 2016 11:21:13 -0800 crecord: edit during hg crecord should preserve cursor position (issue5041) stable
Laurent Charignon <lcharignon@fb.com> [Wed, 20 Jan 2016 11:21:13 -0800] rev 27914
crecord: edit during hg crecord should preserve cursor position (issue5041) This patch adds a variable to keep track of what hunk was selected before the edit. We use that variable to select the hunk or its replacement after the edit.
Thu, 21 Jan 2016 02:42:01 +0900 templates: use canvaswidth instead of fixed width for canvas (issue2683) stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 21 Jan 2016 02:42:01 +0900] rev 27913
templates: use canvaswidth instead of fixed width for canvas (issue2683) Before this patch, template files for "graph" web page use fixed width size "480" for canvas element. This causes pruned lanes and invisible vertexes, if there are 16 or more vertical lanes at once. In such case, part of graph in right side area over 480 is invisible, even though corresponded summary text blocks are visible correctly. This limitation isn't reasonable for workflow using many branches at once (e.g. "one branch per issue" workflow). There were changes below related to width of canvas: - 7359cb753a54 (templates: widen the graph canvas (issue2683)), released as a part of Mercurial 1.8.2 According to the description, this assumed that 15 parallel branches was enough for ordinary workflow, and bumped width of canvas up from 224 to 480. - d490edc71146 (hgweb: make graph data suitable for template usage), released as a part of Mercurial 2.3 This introduced "canvaswidth" template keyword as a part of refactoring around graph rendering. But 'width="480"' of canvas element in template files wasn't replaced by 'width="{canvaswidth}"' in it (or subsequent one). This patch uses dynamic value "{canvaswidth}" instead of fixed width size "480" for canvas element. This is posted for "stable", because: - this is re-fixing issue2683 - this is simple enough for stable - using "{canvaswidth}" doesn't require any additional cost Calculation of canvaswidth is already implied as a part of "graph" web command.
Wed, 20 Jan 2016 08:16:58 -0800 backout: fix --no-commit option (issue5054) stable
Ruslan Sayfutdinov <sayfutdinov@fb.com> [Wed, 20 Jan 2016 08:16:58 -0800] rev 27912
backout: fix --no-commit option (issue5054)
Tue, 19 Jan 2016 13:43:50 -0800 bundle: exit early when there are no commits to bundle stable
Durham Goode <durham@fb.com> [Tue, 19 Jan 2016 13:43:50 -0800] rev 27911
bundle: exit early when there are no commits to bundle Previously, if you passed a revset that resolved to no nodes, it would get interpreted by the changegroup discovery logic as 'bundle all my heads', which is not what the user asked. Let's exit early when we notice this case. It could be argued that the changeset discovery logic should be smarter and only assume 'all heads' if the incoming heads parameter is None, but that's a much riskier change.
Sun, 17 Jan 2016 20:37:29 -0800 zeroconf: access repo on hgweb_mod properly (issue5036) stable
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 17 Jan 2016 20:37:29 -0800] rev 27910
zeroconf: access repo on hgweb_mod properly (issue5036) hgweb_mod.hgweb.repo disappeared in ae33fff17c1e (hg: establish a cache for localrepository instances) and the code for accessing repo instances from hgweb was later refactored to go through a cache-aware context manager. Adapt zeroconf to access the repo instance via the new API.
Sun, 17 Jan 2016 21:40:21 -0600 merge default into stable for 3.7 code freeze stable
Matt Mackall <mpm@selenic.com> [Sun, 17 Jan 2016 21:40:21 -0600] rev 27909
merge default into stable for 3.7 code freeze
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip