Sun, 24 Jan 2016 00:10:19 -0500 largefiles: prevent committing a missing largefile stable
Matt Harbison <matt_harbison@yahoo.com> [Sun, 24 Jan 2016 00:10:19 -0500] rev 27947
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.
Wed, 27 Jan 2016 10:24:25 -0500 changegroup: fix treemanifest exchange code (issue5061) stable
Augie Fackler <augie@google.com> [Wed, 27 Jan 2016 10:24:25 -0500] rev 27946
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.
Fri, 22 Jan 2016 12:08:20 -0600 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 27945
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.
Sat, 23 Jan 2016 23:32:49 -0500 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 27944
largefiles: report the missing file count after a commit that does nothing This is the same warning that is printed for normal files.
Sat, 23 Jan 2016 23:24:30 -0500 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 27943
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.
Sat, 23 Jan 2016 20:51:17 -0500 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 27942
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]
Mon, 25 Jan 2016 15:48:35 -0800 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 27941
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.
Thu, 23 Jul 2015 23:41:29 +0900 templater: abort if infinite recursion detected while compiling stable
Yuya Nishihara <yuya@tcha.org> [Thu, 23 Jul 2015 23:41:29 +0900] rev 27940
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')]
(0) -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 +10000 tip