Tue, 28 Oct 2014 00:19:18 +0900 tests: use "%HG_ARGS%" in shell alias on Windows instead of "$HG_ARGS" stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 28 Oct 2014 00:19:18 +0900] rev 23093
tests: use "%HG_ARGS%" in shell alias on Windows instead of "$HG_ARGS" Before this patch, a part of "test-alias.t" fails unexpectedly on Windows environment, because "cmd.exe" can't evaluate "$HG_ARGS" expression in shell alias correctly. This patch uses "%HG_ARGS%" in shell alias on Windows instead of "$HG_ARGS" to expand it correctly.
Tue, 28 Oct 2014 00:19:18 +0900 tests: introduce "checkeditform-n-cat.sh" script to invoke "cat" in it safely stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 28 Oct 2014 00:19:18 +0900] rev 23092
tests: introduce "checkeditform-n-cat.sh" script to invoke "cat" in it safely Before this patch, a part of "test-transplant.t" fails unexpectedly on Windows environment, because semicolon (";") in HGEDITOR isn't recognized as the command separator by "cmd.exe". This patch newly introduces "checkeditform-n-cat.sh" script to invoke "cat" in it safely anywhere.
Fri, 24 Oct 2014 13:50:00 -0400 doc: change 'revision or range' to 'revision or revset' stable
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Fri, 24 Oct 2014 13:50:00 -0400] rev 23091
doc: change 'revision or range' to 'revision or revset' The phrase "revision or range" comes from a pre-revset era. Since the documentation for ranges now is under the revset docs, and as a helpful hint nudging users towards revsets, I think it's better to say "revision or revset"
Tue, 28 Oct 2014 01:14:12 +0900 largefiles: add examination of exec bit in "hg status --rev REV" case stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 28 Oct 2014 01:14:12 +0900] rev 23090
largefiles: add examination of exec bit in "hg status --rev REV" case Before this patch, "hg status --rev REV" doesn't list largefiles up with "M" mark, even if exec bit of them is changed, because "lfilesrepo.status" doesn't examine exec bit in such case.
Tue, 28 Oct 2014 01:14:11 +0900 largefiles: ignore removal status of files not managed in the target context stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 28 Oct 2014 01:14:11 +0900] rev 23089
largefiles: ignore removal status of files not managed in the target context Before this patch, "hg status --rev REV" listed largefiles removed in the working directory up with "R" mark, even if they aren't managed in the REV. Normal files aren't listed up in such case. When "lfilesrepo.status" is invoked for "hg status --rev REV", it treats files on conditions below as "removed" (to avoid manifest full scan in "ctx.status" ?): - marked as "R" in lfdirstate, or - files managed in the target revision but unknown in the manifest of the working context (= not including "R" files) But the former can include files not managed in the target context. To ignore removal status of files not managed in the target context, this patch drops files unknown in the target revision from "removed" list.
Sun, 26 Oct 2014 12:14:12 +0100 changelog: use headrevsfiltered stable
Mads Kiilerich <madski@unity3d.com> [Sun, 26 Oct 2014 12:14:12 +0100] rev 23088
changelog: use headrevsfiltered 2b5940f64750 introduced use of the new filtering headrevs C implementation. It caught TypeError to detect when to fall back to the implementation that was compatible with old extensions. That method was however not reliable. Instead, use the new headrevsfiltered function when passing a filter. It will reliably fail with AttributeError when an old extension that predates headrevsfiltered is used.
Sun, 26 Oct 2014 12:14:10 +0100 parsers: introduce headrevsfiltered in C extension stable
Mads Kiilerich <madski@unity3d.com> [Sun, 26 Oct 2014 12:14:10 +0100] rev 23087
parsers: introduce headrevsfiltered in C extension All extensions that have this function do support filtering. The existing headrevs function may support filtering but we cannot reliably detect whether it does.
Sat, 25 Oct 2014 21:34:49 -0400 httppeer: close the temporary bundle file after two-way streaming it stable
Matt Harbison <matt_harbison@yahoo.com> [Sat, 25 Oct 2014 21:34:49 -0400] rev 23086
httppeer: close the temporary bundle file after two-way streaming it This fixes several push tests in test-bundle2-exchange.t that were failing on Windows with messages like the following: $ hg -R main push http://localhost:$HGPORT2/ -r 32af7686d403 \ --bookmark book_32af pushing to http://localhost:$HGPORT2/ searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 1 changes to 1 files remote: 1 new obsolescence markers updating bookmark book_32af abort: The process cannot access the file because it is being used by another process: 'C:\path\to\tmp\bundle.hg' [255]
Fri, 24 Oct 2014 14:24:28 -0700 status: make 'hg status --rev' faster when there are deleted files stable
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Oct 2014 14:24:28 -0700] rev 23085
status: make 'hg status --rev' faster when there are deleted files In order not to avoid listing files as both added and deleted, for example, we check for every file in the manifest if it is in the _list_ of deleted files. This can get quite slow when there are many deleted files. Change it to a set to make the containment check faster. On a somewhat contrived example of the Mozilla repo with the entire testing/ directory deleted (~14k files), this makes 'hg status --rev .^' go from 26s to 2s.
Mon, 27 Oct 2014 17:52:33 +0100 setdiscovery: limit the size of the initial sample (issue4411) stable
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 27 Oct 2014 17:52:33 +0100] rev 23084
setdiscovery: limit the size of the initial sample (issue4411) The set discovery start by sending a "known" command with all local heads. When the number of local heads is massive (eg: using hidden changesets) such request becomes too large. This lead to 414 error over http, aborting the whole process. We limit the size of the sample used by the first query to fix this. The test are impacted because they do test massive number of heads. But they do not test it over real world http setup.
Mon, 27 Oct 2014 17:40:32 +0100 setdiscovery: extract sample limitation in a `_limitsample` function stable
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 27 Oct 2014 17:40:32 +0100] rev 23083
setdiscovery: extract sample limitation in a `_limitsample` function We need to reuse this logic for the initial query. We extract it in a function to unsure sample limiting is applied consistently in all cases.
Fri, 24 Oct 2014 17:24:46 -0500 exchange: don't report failure from identical bookmarks stable
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 24 Oct 2014 17:24:46 -0500] rev 23082
exchange: don't report failure from identical bookmarks b901645a8784 regressed the behavior of pushing an unchanged bookmark to a remote. Before that commit, pushing a unchanged bookmark would result in "exporting bookmark @" being printed. After that commit, we now see an incorrect message "bookmark %s does not exist on the local or remote repository!" This patch fixes the regression introduced by b901645a8784 by having the bookmark error reporting code filter identical bookmarks and adds a test for the behavior.
Fri, 24 Oct 2014 10:40:37 -0700 bookmarks: explicitly track identical bookmarks stable
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 24 Oct 2014 10:40:37 -0700] rev 23081
bookmarks: explicitly track identical bookmarks bookmarks.compare() previously lumped identical bookmarks in the "invalid" bucket. This patch adds a "same" bucket. An 8-tuple for holding this state is pretty gnarly. The return value should probably be converted into a class to increase readability. But that is beyond the scope of a patch intended to be a late arrival to stable.
Fri, 24 Oct 2014 15:52:20 -0500 context.status: remove incorrect swapping of added/removed in workingctx stable
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Oct 2014 15:52:20 -0500] rev 23080
context.status: remove incorrect swapping of added/removed in workingctx The comment in workingctx.status() says that "calling 'super' subtly reveresed the contexts", but that is simply not true, so we should not be swapping added and removed fields.
Thu, 23 Oct 2014 13:17:37 -0700 keyword: use parent of working copy as base for status stable
Martin von Zweigbergk <martinvonz@google.com> [Thu, 23 Oct 2014 13:17:37 -0700] rev 23079
keyword: use parent of working copy as base for status Instead of calling repo[None].status(), use the more common form that uses the parent of the working copy as the base: repo['.'].status(). Note that the former defaults to comparing to revision '.', while the latter defaults to revision None, so the contexts being compared are the same. It might seem like this would result in a reverse diff, but it turns out that workingctx.status() incorrectly reverses the result. That bug will be fixed in a later commit.
Thu, 23 Oct 2014 21:53:37 +0900 revset: avoid O(n) lookup of invalid revision in rev() stable
Yuya Nishihara <yuya@tcha.org> [Thu, 23 Oct 2014 21:53:37 +0900] rev 23078
revset: avoid O(n) lookup of invalid revision in rev() ba89f7b542c9 was not the final version of that patch. It was really slow because `l not in repo.changelog` iterates revisions up to `l`. Instead, rev() should utilize spanset.__contains__(). revset #0: rev(210000) 0) wall 0.000039 comb 0.000000 user 0.000000 sys 0.000000 (best of 67978) 1) wall 0.002721 comb 0.000000 user 0.000000 sys 0.000000 (best of 1055) 2) wall 0.000059 comb 0.000000 user 0.000000 sys 0.000000 (best of 45599) (0: 3.2-rc, 1: ba89f7b542c9, 2: this patch) Note that the benchmark result described in ba89f7b542c9 is wrong because it is the one of the initial version.
Thu, 23 Oct 2014 13:44:34 -0500 run-tests: output diffs with only forward slashes stable
Matt Mackall <mpm@selenic.com> [Thu, 23 Oct 2014 13:44:34 -0500] rev 23077
run-tests: output diffs with only forward slashes This removes some gratuitous variance when testing on Windows with test-run-tests.t.
Thu, 23 Oct 2014 12:35:10 -0200 i18n: add hint to digest mismatch message stable
Wagner Bruna <wbruna@softwareexpress.com.br> [Thu, 23 Oct 2014 12:35:10 -0200] rev 23076
i18n: add hint to digest mismatch message
Thu, 23 Oct 2014 12:28:00 -0200 help/config: fix typo stable
Wagner Bruna <wbruna@softwareexpress.com.br> [Thu, 23 Oct 2014 12:28:00 -0200] rev 23075
help/config: fix typo
Thu, 23 Oct 2014 12:27:57 -0200 files: fix example list syntax stable
Wagner Bruna <wbruna@softwareexpress.com.br> [Thu, 23 Oct 2014 12:27:57 -0200] rev 23074
files: fix example list syntax
Thu, 23 Oct 2014 02:42:57 +0200 parsers: use 'k' format for Py_BuildValue instead of 'n' because Python 2.4 stable
Mads Kiilerich <madski@unity3d.com> [Thu, 23 Oct 2014 02:42:57 +0200] rev 23073
parsers: use 'k' format for Py_BuildValue instead of 'n' because Python 2.4 'n' was introduced in Mercurial in 2b5940f64750 and broke Python 2.4 support in mysterious ways that only showed failure in test-glog.t. Py_BuildValue failed because of the unknown format and a TypeError was thrown ... but it never showed up on the Python side and it happily continued processing with wrong data. Quoting https://docs.python.org/2/c-api/arg.html : n (integer) [Py_ssize_t] Convert a Python integer or long integer to a C Py_ssize_t. New in version 2.5. k (integer) [unsigned long] Convert a Python integer or long integer to a C unsigned long without overflow checking. This will use unsigned long instead of Py_ssize_t. That is not a good solution, but good is not an option when we have to support Python 2.4.
Mon, 20 Oct 2014 18:50:09 -0700 rebase: improve base revset performance stable
Durham Goode <durham@fb.com> [Mon, 20 Oct 2014 18:50:09 -0700] rev 23072
rebase: improve base revset performance The old revset had pretty terrible performance on large repositories (12+ seconds). This new revset achieves the same result in only 0.7s. As we improve the underlying revset APIs we can probably get this revset down to 'only(base, dest)::', but at the moment that version still takes 2s.
Thu, 16 Oct 2014 06:35:06 -0700 amend: fix amending rename commit with diverged topologies (issue4405) stable
Ryan McElroy <rmcelroy@fb.com> [Thu, 16 Oct 2014 06:35:06 -0700] rev 23071
amend: fix amending rename commit with diverged topologies (issue4405) This addresses the bug described in issue4405: when obsolescence markers are enabled, amending a commit with a file move can lead to the copy information being lost. However, the bug is more general and can be reproduced without obsmarkers as well, as demonstracted by Pierre-Yves and put into the updated test. Specifically, graph topology divergences between the filelogs and the changelog can cause copy information to be lost during amends.
Tue, 21 Oct 2014 17:09:37 -0400 hgweb: disable SSLv3 serving (BC) stable
Augie Fackler <raf@durin42.com> [Tue, 21 Oct 2014 17:09:37 -0400] rev 23070
hgweb: disable SSLv3 serving (BC) Because of recent attacks[0] on SSLv3, let's just drop support entirely. 0: http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html
Tue, 21 Oct 2014 17:01:23 -0400 sslutil: only support TLS (BC) stable
Augie Fackler <raf@durin42.com> [Tue, 21 Oct 2014 17:01:23 -0400] rev 23069
sslutil: only support TLS (BC) In light of the POODLE[0] attack on SSLv3, let's just drop the ability to use anything older than TLSv1 entirely. This only fixes the client side. Another commit will fix the server side. There are still a few SSLv[23] constants hiding in httpclient, but I'll fix those separately upstream and import them when we're not in a code freeze. 0: http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html
Wed, 22 Oct 2014 16:10:23 +0200 eol: fix crash when handling removed files stable
Mads Kiilerich <madski@unity3d.com> [Wed, 22 Oct 2014 16:10:23 +0200] rev 23068
eol: fix crash when handling removed files ci --amend would in some cases fail after 650b5b6e75ed failed to refactor the eol extension too.
Wed, 15 Oct 2014 03:52:20 -0700 bundle2: transmit exception during part generation stable
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 15 Oct 2014 03:52:20 -0700] rev 23067
bundle2: transmit exception during part generation If an exception is raised during a bundle2 part payload generation it is now recorded in the bundle. If such exception occurs, we capture it, transmit an abort exception through the bundle, cleanly close the current part payload and raise it again. This allow to generate valid bundle even in case of exception so that the consumer does not wait forever for a dead producer. This also allow to raise the exception during unbundling at the exact point it happened during bundling make debugging easier.
Tue, 14 Oct 2014 10:47:47 -0700 bundle2: add a interrupt mechanism stable
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 14 Oct 2014 10:47:47 -0700] rev 23066
bundle2: add a interrupt mechanism It is now possible to emit a single part in the middle of a payload production. This part will be processed with limitation (only access to a `ui` object). The goal is to let the server raise exception and output while a part is being processed. The source motivation is to transmit exception that occurs while generating a part. This change is was the motivation to bump the bundle2 format from HG2X to HG2Y. Somehow, the format bump made it into 3.2 without it. So this change go on stable. It is low risk as bundle2 is still disabled by default.
Tue, 21 Oct 2014 12:38:28 -0700 transactions: change backupfiles format to use newlines stable
Durham Goode <durham@fb.com> [Tue, 21 Oct 2014 12:38:28 -0700] rev 23065
transactions: change backupfiles format to use newlines Previously the journal.backupfiles file was delimited by \0. Now we delimit it using \n (same as the journal file). This allows us to change the number of values in each line more easily, rather than relying on the count of \0's.
Tue, 21 Oct 2014 11:37:29 -0700 transactions: add version number to journal.backupfiles stable
Durham Goode <durham@fb.com> [Tue, 21 Oct 2014 11:37:29 -0700] rev 23064
transactions: add version number to journal.backupfiles The transaction format will be changing a bit over the next releases, so let's go ahead and add a version number to make backwards compatibility easier. This whole file format was broken prior to 3.2 (see previous patch), so changing it now is pretty low risk.
(0) -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip