Mon, 25 Jan 2016 11:37:02 -0800 crecord: fix help bar display issue (issue5063) stable
Laurent Charignon <lcharignon@fb.com> [Mon, 25 Jan 2016 11:37:02 -0800] rev 27937
crecord: fix help bar display issue (issue5063) Before this patch, the help bar in crecord wouldn't be printed correctly when the terminal window didn't have enough column to display it. This patch adds logic to make sure that the help bar message is always displayed. We use an ellipsis when it is not possible to display the complete message.
Mon, 25 Jan 2016 10:13:03 -0800 crecord: fix typo in the help text stable
Laurent Charignon <lcharignon@fb.com> [Mon, 25 Jan 2016 10:13:03 -0800] rev 27936
crecord: fix typo in the help text In the crecord help dialog, the toggle all option was wrongfully documented. Instead of using 'a', one must use 'A' to toggle all the hunks. The crecord header that is always displayed on the screen contains the right shortcut and does not need to be changed.
Sun, 17 Jan 2016 22:53:57 -0500 subrepo: better error messages in _ensuregit stable
Mason Malone <mason.malone@gmail.com> [Sun, 17 Jan 2016 22:53:57 -0500] rev 27935
subrepo: better error messages in _ensuregit This patch improves the error messages raised when an OSError occurs, since simply re-raising the exception can be both confusing and misleading. For example, if "hg identify" is run inside a repository that contains a Git subrepository and the git binary could not be found, it'll exit with the message "abort: No such file or directory". That implies "identify" has a problem reading the repository itself. There's no way for the user to know what the real problem is unless they dive into the Mercurial source, which is what I ended up doing after spending hours debugging errors while provisioning a VM with Ansible (turns out I forgot to install Git on it). Descriptive errors are especially important on Windows, since it's common for Windows users to forget to set the "Path" system variable after installing Git.
Sat, 23 Jan 2016 17:31:31 +0800 hgweb: update canvas.width before dynamically redrawing graph (issue2683) stable
Anton Shestakov <av6@dwimlabs.net> [Sat, 23 Jan 2016 17:31:31 +0800] rev 27934
hgweb: update canvas.width before dynamically redrawing graph (issue2683) After 91ac8cb79125 graph canvas width is decided once on the initial rendering. However, after graph page gets scrolled down to load more, it might need more horizontal space to draw, so it needs to resize the canvas dynamically. The exact problem that this patch solves can be seen using: hg init testfork cd testfork echo 0 > foo hg ci -Am0 echo 1 > foo hg ci -m1 hg up 0 echo 2 > foo hg ci -m2 hg gl -T '{rev}\n' @ 2 | | o 1 |/ o 0 hg serve And then by navigating to http://127.0.0.1:8000/graph/tip?revcount=1 "revcount=1" makes sure the initial graph contains only revision 2. And because the initial canvas width takes only that one revision into count, after the (immediate) AJAX update revision 1 will be cut off from the graph. We can safely set canvas width to the new value we get from the AJAX request because every time graph is updated, it is completely redrawn using all the requested nodes (in the case above it will use /graph/2?revcount=61), so the value is guaranteed not to decrease. P.S.: Sorry for parsing HTML with regexes, but I didn't start it.
Fri, 22 Jan 2016 11:00:13 -0800 run-tests: "fix" race condition in race condition fix stable
Bryan O'Sullivan <bryano@fb.com> [Fri, 22 Jan 2016 11:00:13 -0800] rev 27933
run-tests: "fix" race condition in race condition fix Laurent's commit 3203dfe341f9 still suffers from a race: by the time the "job" function tries to assign to channels[channel], that list has been truncated to empty. The result is that every job thread raises an IndexError. Earlier, I tried an approach of correctly locking channels, but that caused run-tests to hang on KeyboardInterrupt sometimes. This approach is strictly hackier, but seems to actually work reliably.
Fri, 22 Jan 2016 20:32:47 +0000 rebase: restore help for rebase w/o args (issue5059) stable
timeless <timeless@mozdev.org> [Fri, 22 Jan 2016 20:32:47 +0000] rev 27932
rebase: restore help for rebase w/o args (issue5059) Restoring documentation accidentally removed in a9a047878e14.
Tue, 19 Jan 2016 15:37:07 -0800 shelve: use cg3 for treemanifests stable
Martin von Zweigbergk <martinvonz@google.com> [Tue, 19 Jan 2016 15:37:07 -0800] rev 27931
shelve: use cg3 for treemanifests Similar to previous change, this teaches shelve to pick the right changegroup version for repos that use treemanifests.
Tue, 19 Jan 2016 15:38:24 -0800 repair: use cg3 for treemanifests stable
Martin von Zweigbergk <martinvonz@google.com> [Tue, 19 Jan 2016 15:38:24 -0800] rev 27930
repair: use cg3 for treemanifests The newly created helper changegroup.safeversion() knows to pick version 03 if the repo uses treemanifests, so just using that means we pick the right changegroup version.
Tue, 19 Jan 2016 15:32:32 -0800 changegroup: introduce safeversion() stable
Martin von Zweigbergk <martinvonz@google.com> [Tue, 19 Jan 2016 15:32:32 -0800] rev 27929
changegroup: introduce safeversion() In a few places (at least repair.py and shelve.py), we want to find the best changegroup version that we can assume users of the repo will understand. For example, we choose version 01 by default, but if it's a generaldelta repo, we expect clients to support version 02 anyway, so we choose that for new bundles (for e.g. "hg strip"). Let's create a helper for this functionality in changegroup, so we can reuse it elsewhere later.
Tue, 19 Jan 2016 14:27:18 -0800 changegroup: don't support versions 01 and 02 with treemanifests stable
Martin von Zweigbergk <martinvonz@google.com> [Tue, 19 Jan 2016 14:27:18 -0800] rev 27928
changegroup: don't support versions 01 and 02 with treemanifests Since it would be terribly expensive to convert between flat manifests and treemanifests, we have decided to simply not support changegroup version 01 and 02 with treemanifests. Therefore, let's stop announcing that we support these versions on treemanifest repos. Note that this means that older clients that try to clone from a treemanifest repo will fail. What happens is that the server, after this patch, finds that there are no common versions and raises "ValueError: no common changegroup version". This results in "abort: HTTP Error 500: Internal Server Error" on the client. Before this patch, it was no better: The server would instead find that there were directory manifest nodes to put in the changegroup 01 or 02 and raise an AssertionError on changegroup.py#668 (assert not tmfnodes), which would also appear as a 500 to the client.
Tue, 19 Jan 2016 08:22:27 -0800 run-tests: fix crash when --json and --blacklist are both used (issue5050) stable
Laurent Charignon <lcharignon@fb.com> [Tue, 19 Jan 2016 08:22:27 -0800] rev 27927
run-tests: fix crash when --json and --blacklist are both used (issue5050) This patch fixes a crash when both --json and --blacklist were given as arguments of run-tests.py. Now, instead of crashing, we add an entry for blacklisted tests in the json output to show that the tests were skipped.
Thu, 21 Jan 2016 12:37:12 -0800 run-tests: fix race condition stable
Laurent Charignon <lcharignon@fb.com> [Thu, 21 Jan 2016 12:37:12 -0800] rev 27926
run-tests: fix race condition Before this patch, it was possible for run-tests to crash on a race condition. The race condition happens in the following case: - the last test finishes and calls: done.put(None) - the context switches to the main thread that clears the channels list - the context switches to the last test mentioned above, it tries to access channels[channel] and crashes This happened to me while running run-tests. This patch fixes the issue by clearing the channel before considering that the test is done.
(0) -10000 -3000 -1000 -300 -100 -12 +12 +100 +300 +1000 +3000 +10000 tip