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]
(0) -10000 -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 +1000 +3000 +10000 tip