c5ffbd4c033ba82942e51d03e05cf7df2de69d2f: tests: minor cleanup to treemanifest test stable
Martin von Zweigbergk <martinvonz@google.com> - Thu, 28 Jan 2016 13:49:05 -0800 - rev 29901
Push 175 by gszorc@mozilla.com at Wed, 10 Feb 2016 01:24:28 +0000
tests: minor cleanup to treemanifest test
6bce6d925e4569a7b57620d33dc3480d13b3cca1: merge: don't try to merge subrepos twice (issue4988) stable
Siddharth Agarwal <sid0@fb.com> - Fri, 29 Jan 2016 14:19:29 -0800 - rev 29900
Push 175 by gszorc@mozilla.com at Wed, 10 Feb 2016 01:24:28 +0000
merge: don't try to merge subrepos twice (issue4988) In my patch series ending with rev 25e4b2f000c5 I switched most change/delete conflicts to be handled at the resolve layer. .hgsubstate was the one file that we weren't able to handle, so we kept the old code path around for it. The old code path added .hgsubstate to one of the other lists as the user specifies, including possibly the 'g' list. Now since we did this check after converting the actions from being keyed by file to being keyed by action type, there was nothing that actually removed .hgsubstate from the 'cd' or 'dc' lists. This meant that the file would eventually make its way into the 'mergeactions' list, now freshly augmented with 'cd' and 'dc' actions. We call subrepo.submerge for both 'g' actions and merge actions. This means that if the resolution to an .hgsubstate change/delete conflict was to add it to the 'g' list, subrepo.submerge would be called twice. It turns out that this doesn't cause any adverse effects on Linux due to caching, but apparently breaks on other operating systems including Windows. The fix here moves this to before we convert the actions over. This ensures that it .hgsubstate doesn't make its way into multiple lists. The real fix here is going to be: (1) move .hgsubstate conflict resolution into the resolve layer, and (2) use a real data structure for the actions rather than shuffling data around between lists and dictionaries: we need a hash (or prefix-based) index by file and a list index by action type. There's a very tiny behavior change here: collision detection on case-insensitive systems will happen after this is resolved, not before. I think this is the right change -- .hgsubstate could theoretically collide with other files -- but in any case it makes no practical difference. Thanks to Yuya Nishihara for investigating this.
f0d3c57943801a011d7ec7b8a4b3b8947b004a7f: bookmarks: improve documentation for --rev option stable
Nathan Goldbaum <ngoldbau@ucsc.edu> - Wed, 27 Jan 2016 16:16:38 -0600 - rev 29899
Push 175 by gszorc@mozilla.com at Wed, 10 Feb 2016 01:24:28 +0000
bookmarks: improve documentation for --rev option
7b7e16158c3536f32bde6889fabbda7c6fac848c: merge: undocument checkunknown and checkignored configs for 3.7 stable
Siddharth Agarwal <sid0@fb.com> - Wed, 27 Jan 2016 12:33:07 -0800 - rev 29898
Push 175 by gszorc@mozilla.com at Wed, 10 Feb 2016 01:24:28 +0000
merge: undocument checkunknown and checkignored configs for 3.7 We've discovered an issue with this flag during certain kinds of rebases. When: (1) we're rebasing while currently on the destination commit, and (2) an untracked or ignored file F is currently in the working copy, and (3) the same file F is in a source commit, and (4) F has different contents in the source commit, then we'll try to merge the file rather than overwrite it. An earlier patch I sent honored the options for these situations as well. Unfortunately, rebases go through the same flow as the old, deprecated 'hg merge --force'. We'd rather not make any changes to 'hg merge --force' behavior, and there's no way from this point in the code to figure out whether we're in 'hg rebase' or 'hg merge --force'. Pierre-Yves David and I came up with the idea to split the 'force' flag up into 'force' for rebases, and 'forcemerge' for merge. Since this is a very disruptive change and we're in freeze mode, simply undocument the options for this release so that our hands aren't tied by BC concerns. We'll redocument them in the next release.
7cb7264cfd52d2672644db4bc16a0bd50aa093ca: commands: advance current active bookmark at pull --update correctly stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> - Thu, 28 Jan 2016 20:10:06 +0900 - rev 29897
Push 175 by gszorc@mozilla.com at Wed, 10 Feb 2016 01:24:28 +0000
commands: advance current active bookmark at pull --update correctly Before this patch, "hg pull --update" doesn't advance current active bookmark correctly, if pulling itself doesn't advance it, even though "hg pull" + "hg update" does so. Existing test for "pull --update works the same as pull && update" in test-bookmarks.t doesn't examine this case, because pulling itself advance current active bookmark before actual updating the working directory in that test case. To advance current active bookmark at "hg pull --update" correctly, this patch examines 'movemarkfrom' instead of 'not checkout'. Even if 'not checkout' at the invocation of postincoming(), 'checkout' is overwritten by "the revision to update to" value returned by destutil.destupdate() in such case. Therefore, 'not checkout' condition means "update destination is revision #0", and isn't suitable for examining whether active bookmark should be advanced. Even though examination around "movemarkfrom == repo['.'].node()" may seem a little redundant just for this issue, this makes it easier to compare (and unify in the future, maybe) with the same logic to update bookmark at "hg update" below. if not ret and movemarkfrom: if movemarkfrom == repo['.'].node(): pass # no-op update elif bookmarks.update(repo, [movemarkfrom], repo['.'].node()): ui.status(_("updating bookmark %s\n") % repo._activebookmark) else: # this can happen with a non-linear update ui.status(_("(leaving bookmark %s)\n") % repo._activebookmark) bookmarks.deactivate(repo)
571ba161f6be9ad696efcdbcf8bdf0a8a6ba0766: largefiles: prevent committing a missing largefile stable
Matt Harbison <matt_harbison@yahoo.com> - Sun, 24 Jan 2016 00:10:19 -0500 - rev 29896
Push 175 by gszorc@mozilla.com at Wed, 10 Feb 2016 01:24:28 +0000
largefiles: prevent committing a missing largefile Previously, if the largefile was deleted at the time of a commit, the standin was silently not updated and its current state (possibly garbage) was recorded. The test makes it look like this is somewhat of an edge case, but the same thing happens when an `hg revert` followed by `rm` changes the standin. Aside from the second invocation of this in lfutil.updatestandinsbymatch() (which is what triggers this test case), the three other uses are guarded by dirstate checks for added or modified, or an existence check in the filesystem. So aborting in lfutil.updatestandins() should be safe, and will avoid silent skips in the future if this is used elsewhere.
ca8d2b73155d30d7402391cb48ab6727cd33f9e7: changegroup: fix treemanifest exchange code (issue5061) stable
Augie Fackler <augie@google.com> - Wed, 27 Jan 2016 10:24:25 -0500 - rev 29895
Push 175 by gszorc@mozilla.com at Wed, 10 Feb 2016 01:24:28 +0000
changegroup: fix treemanifest exchange code (issue5061) There were two mistakes: one was accidental reuse of the fclnode variable from the loop gathering file nodes, and the other (masked by that bug) was not correctly handling deleted directories. Both cases are now fixed and the test passes.
4186d359046a87aa303132894dec49bbfb1fd87f: log: speed up single file log with hidden revs (issue4747) stable
Matt Mackall <mpm@selenic.com> - Fri, 22 Jan 2016 12:08:20 -0600 - rev 29894
Push 175 by gszorc@mozilla.com at Wed, 10 Feb 2016 01:24:28 +0000
log: speed up single file log with hidden revs (issue4747) On repos with lots of heads, the filelog() code could spend several minutes decompressing manifests. This change instead tries to efficiently scan the changelog for candidates and decompress as few manifests as possible. This is a regression introduced in 3.3 by the linkrev adjustment code. Prior to that, filelog was nearly instant. For the repo in the bug report, this improves time of a simple log command from ~3 minutes to ~.5 seconds, a 360x speedup. For the main Mercurial repo, a log of commands.py slows down from 1.14s to 1.45s, a 27% slowdown. This is still faster than the file() revset, which takes 2.1 seconds.
4511e8dac4c798e5fed91e629aa9802b01c2b6c3: largefiles: report the missing file count after a commit that does nothing stable
Matt Harbison <matt_harbison@yahoo.com> - Sat, 23 Jan 2016 23:32:49 -0500 - rev 29893
Push 175 by gszorc@mozilla.com at Wed, 10 Feb 2016 01:24:28 +0000
largefiles: report the missing file count after a commit that does nothing This is the same warning that is printed for normal files.
02c5f8ad00ac2e3663a175b691ccce4a1f340c00: commit: factor the post commit status check into a cmdutil method stable
Matt Harbison <matt_harbison@yahoo.com> - Sat, 23 Jan 2016 23:24:30 -0500 - rev 29892
Push 175 by gszorc@mozilla.com at Wed, 10 Feb 2016 01:24:28 +0000
commit: factor the post commit status check into a cmdutil method The largefiles extension needs to set lfstatus for this status call. Otherwise, if a missing largefile is explicitly named, a confusing message is issued that says the largefile wasn't found, followed by another that says nothing changed.
eb1135d5e688f8540fb98a32759317a7eed31985: largefiles: fix an explicit largefile commit after a remove (issue4969) stable
Matt Harbison <matt_harbison@yahoo.com> - Sat, 23 Jan 2016 20:51:17 -0500 - rev 29891
Push 175 by gszorc@mozilla.com at Wed, 10 Feb 2016 01:24:28 +0000
largefiles: fix an explicit largefile commit after a remove (issue4969) The change in b68797f244e4 to handle a normal -> largefile switch was too aggressive in preserving the original matcher names. If a largefile is explicitly provided by the user, but only the standin exists in dirstate, then only the standin can be committed. There's still maybe an issue when the largefile is deleted outside of Mercurial: $ rm large $ hg ci -m "oops" large large: The system cannot find the file specified nothing changed [1]
75fa75d314950be8f96f3476253e0f10c4b3a944: context: back out sneaky code change in documentation change stable
Martin von Zweigbergk <martinvonz@google.com> - Mon, 25 Jan 2016 15:48:35 -0800 - rev 29890
Push 175 by gszorc@mozilla.com at Wed, 10 Feb 2016 01:24:28 +0000
context: back out sneaky code change in documentation change In 81b391a45264 (context: clarify why we don't compare file contents when nodeid differs, 2016-01-12), I also changed "node2 != _newnode" into "self.rev() is not None". I don't remember why. They are similar, but the former also catches the case where the file is clean in the dirstate (so node2 is not _newnode), but different from the "other" context. This resulted in unnecessary file content comparison a few lines further down in the code. Let's just back out the code change. Thanks to Durham Goode for spotting this.
cfe7da66f5550c539a4b8bf46772e1366687f60c: templater: abort if infinite recursion detected while compiling stable
Yuya Nishihara <yuya@tcha.org> - Thu, 23 Jul 2015 23:41:29 +0900 - rev 29889
Push 175 by gszorc@mozilla.com at Wed, 10 Feb 2016 01:24:28 +0000
templater: abort if infinite recursion detected while compiling In this case, a template is parsed recursively with no thunk for lazy evaluation. This patch prevents recursion by putting a dummy of the same name into a cache that will be referenced while parsing if there's a recursion. changeset = {files % changeset}\n ~~~~~~~~~ = [(_runrecursivesymbol, 'changeset')]
7ed3a3c0cef18f11b57aa9fcd38e30dc8ffc6c88: templater: abort if infinite recursion detected while evaluation (issue4758) stable
Yuya Nishihara <yuya@tcha.org> - Wed, 22 Jul 2015 23:29:41 +0900 - rev 29888
Push 175 by gszorc@mozilla.com at Wed, 10 Feb 2016 01:24:28 +0000
templater: abort if infinite recursion detected while evaluation (issue4758) It would be nice if we could detect recursion at the parsing phase, but we can't because a template can refer to a keyword of the same name. For example, "rev = {rev}" is valid if rev is a keyword, and we don't know if rev is a keyword or a template while parsing.
cabac7dfc6214e915908912678ff8e84f5dc7488: exchange: set 'treemanifest' param on pushed changegroups too stable
Martin von Zweigbergk <martinvonz@google.com> - Fri, 22 Jan 2016 16:31:50 -0800 - rev 29887
Push 175 by gszorc@mozilla.com at Wed, 10 Feb 2016 01:24:28 +0000
exchange: set 'treemanifest' param on pushed changegroups too In 5c0fd878779c (treemanifests: set bundle2 part parameter indicating treemanifest, 2016-01-08), I didn't realize I had to set the parameter separately for getbundle and unbundle. Having the parameter there on push allows us to push to an empty repo and have the requirements updated correctly.
3d3b4ac369f2352a48114a8dd73a25da3766e957: crecord: fix help bar display issue (issue5063) stable
Laurent Charignon <lcharignon@fb.com> - Mon, 25 Jan 2016 11:37:02 -0800 - rev 29886
Push 175 by gszorc@mozilla.com at Wed, 10 Feb 2016 01:24:28 +0000
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.
fedd81659643693d3cd211b3936acd0ffe5e6bdd: crecord: fix typo in the help text stable
Laurent Charignon <lcharignon@fb.com> - Mon, 25 Jan 2016 10:13:03 -0800 - rev 29885
Push 175 by gszorc@mozilla.com at Wed, 10 Feb 2016 01:24:28 +0000
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.
594bdc380aa231954268fa8dfd60841af2409672: subrepo: better error messages in _ensuregit stable
Mason Malone <mason.malone@gmail.com> - Sun, 17 Jan 2016 22:53:57 -0500 - rev 29884
Push 175 by gszorc@mozilla.com at Wed, 10 Feb 2016 01:24:28 +0000
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.
1779ff7426c9ef1605e6e1fdb9994a4c836fc459: hgweb: update canvas.width before dynamically redrawing graph (issue2683) stable
Anton Shestakov <av6@dwimlabs.net> - Sat, 23 Jan 2016 17:31:31 +0800 - rev 29883
Push 175 by gszorc@mozilla.com at Wed, 10 Feb 2016 01:24:28 +0000
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.
a6833e464b070c2f51edff8d6e55be79f5d9db22: 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 29882
Push 175 by gszorc@mozilla.com at Wed, 10 Feb 2016 01:24:28 +0000
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.
(0) -10000 -100 -50 -20 +20 +50 +300 +1000 +3000 +10000 tip