Fri, 15 Mar 2019 09:07:23 +0000 manifestcache: skip setup earlier if we don't have the lock
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 15 Mar 2019 09:07:23 +0000] rev 41961
manifestcache: skip setup earlier if we don't have the lock There a no point preparing a closure if we are not going to use it.
Thu, 14 Mar 2019 11:46:18 +0000 manifestcache: test the cache is warm after a commit
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 11:46:18 +0000] rev 41960
manifestcache: test the cache is warm after a commit
Fri, 15 Mar 2019 13:52:36 +0000 manifestcache: stop altering the lru cache order while displaying it
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 15 Mar 2019 13:52:36 +0000] rev 41959
manifestcache: stop altering the lru cache order while displaying it Accessing value with `.get` alter the iteration order and make the output of the debug command misbehave, showing multiple entry twice. We need more than 2 entry to see the bug, so there are not test change. Later test will introduce a third entry and would fail without this fix.
Fri, 15 Mar 2019 13:52:56 +0000 manifestcache: support multiple cache addition in one debug command run
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 15 Mar 2019 13:52:56 +0000] rev 41958
manifestcache: support multiple cache addition in one debug command run This is more practical.
Thu, 14 Mar 2019 18:11:22 -0700 wix: autogenerate wxs file for library files
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 14 Mar 2019 18:11:22 -0700] rev 41957
wix: autogenerate wxs file for library files Currently, dist.wxs contains an enumeration of .pyd and .dll files staged to dist/lib by py2exe. Having a manual list of files is error prone, as things can easily get out of sync (as the previous commit demonstrates). This is especially an issue for TortoiseHG, which ships a number of custom modules, which may pull in additional dependencies. Let's prevent this problem from manifesting by dynamically generating a .wxs file containing the .pyd and .dll files staged by py2exe. Differential Revision: https://phab.mercurial-scm.org/D6139
Thu, 14 Mar 2019 17:59:51 -0700 wix: introduce variable to hold path to wix packaging directory
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 14 Mar 2019 17:59:51 -0700] rev 41956
wix: introduce variable to hold path to wix packaging directory For convenience. Differential Revision: https://phab.mercurial-scm.org/D6138
Thu, 14 Mar 2019 18:25:23 -0700 wix: package missing .dll and .pyd files
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 14 Mar 2019 18:25:23 -0700] rev 41955
wix: package missing .dll and .pyd files dist.wxs is currently missing some .pyd and .dll files which are picked up and staged by py2exe. This means that the WiX installer is missing some Python extension modules and their dependencies which are referenced by Mercurial or a Python package distributed with it. This commit adds the missing files to the WiX installer. Differential Revision: https://phab.mercurial-scm.org/D6137
Thu, 14 Mar 2019 18:25:07 -0700 setup: exclude crypt32.dll in py2exe builds
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 14 Mar 2019 18:25:07 -0700] rev 41954
setup: exclude crypt32.dll in py2exe builds py2exe is picking up crypt32.dll as a dependency and is including the DLL in the dist/lib directory, where it can get picked up by an installer and distributed. crypt32.dll is a core Windows DLL since Windows XP. We don't need to distribute it. Differential Revision: https://phab.mercurial-scm.org/D6136
Thu, 14 Mar 2019 13:27:37 -0700 packaging: don't bundle DLLs in py2exe library.zip for x86 builds
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 14 Mar 2019 13:27:37 -0700] rev 41953
packaging: don't bundle DLLs in py2exe library.zip for x86 builds I had ported the x86/x64 behavior difference from the Inno Setup installer files. Why things were this way, I'm not sure. The WiX configuration files are expecting to have standalone DLL files for both configurations. And the 32-bit WiX installers were broken due to missing DLLs. Let's standardize on standalone DLL files on all configurations for consistency. I /think/ this will be faster, as I /think/ py2exe binaries would have to extract the DLL to a temporary file in order to load it. But I'm not 100% sure about that. Differential Revision: https://phab.mercurial-scm.org/D6135
Thu, 14 Mar 2019 18:14:33 -0700 packaging: convert files to LF
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 14 Mar 2019 18:14:33 -0700] rev 41952
packaging: convert files to LF My editor accidentally wrote CRLF line endings because I authored this code on Windows. Derp. I'm kinda surprised no linters caught this... # no-check-commit to avoid false positive for foo_bar names Differential Revision: https://phab.mercurial-scm.org/D6134
Wed, 13 Mar 2019 10:51:40 -0700 dirstate: remove obsolete reference to dirstate.beginparentchange
Martin von Zweigbergk <martinvonz@google.com> [Wed, 13 Mar 2019 10:51:40 -0700] rev 41951
dirstate: remove obsolete reference to dirstate.beginparentchange The only valid API since 265e91da56fd (dirstate: drop deprecated methods (API), 2018-02-02) is the context manager returned from dirstate.parentchange(). Differential Revision: https://phab.mercurial-scm.org/D6126
Sat, 09 Mar 2019 00:44:26 +0000 py3: use pycompat.iterbytestr to convert memoryview slice to bytestring
Ian Moody <moz-ian@perix.co.uk> [Sat, 09 Mar 2019 00:44:26 +0000] rev 41950
py3: use pycompat.iterbytestr to convert memoryview slice to bytestring Otherwise ch is the int value of the byte in py3 rather than the actual character. Differential Revision: https://phab.mercurial-scm.org/D6103
Thu, 14 Mar 2019 14:46:29 -0700 rebase: fix crash with in-memory rebase and copies
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Mar 2019 14:46:29 -0700] rev 41949
rebase: fix crash with in-memory rebase and copies When using regular on-disk rebase, filectx.markcopies() calls to dirstate.copy(), which happily records the copy. Then it's simply ignored if it doesn't matter for the commit (as in the test case I added in the previous patch). Let's do the same for overlayworkingctx. Differential Revision: https://phab.mercurial-scm.org/D6133
Thu, 14 Mar 2019 13:53:20 -0700 test: demonstrate crash with in-memory rebase and copies
Martin von Zweigbergk <martinvonz@google.com> [Thu, 14 Mar 2019 13:53:20 -0700] rev 41948
test: demonstrate crash with in-memory rebase and copies In the added test case, there is a merge commit that has one obsolete parent with a rename. Since the rename is not in the other parent, pathcopies() from that other parent will include the copy. Then when we try to rebase this merge commit onto another commit that has the same content changes, but no tracking of the rename (because it was done with "hg remove; hg add" instead of "hg mv"), we try to propagate the copy information. That fails because overlayworkingctx expects a file to be modified if it's going to have copy information. Differential Revision: https://phab.mercurial-scm.org/D6132
Thu, 14 Mar 2019 09:12:46 +0000 manifestcache: actually honor --clear
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 09:12:46 +0000] rev 41947
manifestcache: actually honor --clear Before this change, the --clear flag was not clearing the on disk cache. (We also remove the extra verbosity when using --clear. Same as what we did for --add)
Thu, 14 Mar 2019 10:58:53 +0000 manifestcache: make sure the entry are ordered by access time
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 10:58:53 +0000] rev 41946
manifestcache: make sure the entry are ordered by access time This is an LRU cache, let us make sure of that.
Thu, 14 Mar 2019 09:12:27 +0000 manifestcache: adding a second distinct entry
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 09:12:27 +0000] rev 41945
manifestcache: adding a second distinct entry Let makes sure the cache can hold multiple value.
Thu, 14 Mar 2019 10:53:28 +0000 manifestcache: test that adding the same entry twice do not duplicates it
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 10:53:28 +0000] rev 41944
manifestcache: test that adding the same entry twice do not duplicates it Simple sanity check.
Thu, 14 Mar 2019 09:11:41 +0000 manifestcache: do not display data when using --add
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 09:11:41 +0000] rev 41943
manifestcache: do not display data when using --add If the command invocation is about adding a new entry, we should remain terse (the same as we do for many commands).
Thu, 14 Mar 2019 10:43:01 +0000 manifestcache: only lock the repository if the debug command touch the cache
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 10:43:01 +0000] rev 41942
manifestcache: only lock the repository if the debug command touch the cache Not doing so had two consequences: 1) the command cannot be run on read only repositories, 2) when using --add on an empty cache, the command crash prematurely trying to read the cache file on disk.
Thu, 14 Mar 2019 10:24:51 +0000 manifestcache: further fix to debug command output
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 10:24:51 +0000] rev 41941
manifestcache: further fix to debug command output Removing more capital letters. The output will get a test once other issues get fixed.
Thu, 14 Mar 2019 09:11:18 +0000 manifestcache: test and fix some output of the debug command
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 09:11:18 +0000] rev 41940
manifestcache: test and fix some output of the debug command The message was lacking an end of line. In addition we do not capitalize output in Mercurial.
Thu, 27 Dec 2018 13:36:17 -0800 chunkselector: fix typos in instructions when user reviews patch
Kyle Lippincott <spectral@google.com> [Thu, 27 Dec 2018 13:36:17 -0800] rev 41939
chunkselector: fix typos in instructions when user reviews patch Differential Revision: https://phab.mercurial-scm.org/D6121
Mon, 11 Mar 2019 14:04:48 -0700 scmutil: document matcher argument of movedirstate()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 11 Mar 2019 14:04:48 -0700] rev 41938
scmutil: document matcher argument of movedirstate() Differential Revision: https://phab.mercurial-scm.org/D6120
Mon, 11 Mar 2019 09:42:29 -0700 uncommit: move _movedirstate() to scmutil for reuse
Martin von Zweigbergk <martinvonz@google.com> [Mon, 11 Mar 2019 09:42:29 -0700] rev 41937
uncommit: move _movedirstate() to scmutil for reuse The function should be applicable generically when moving from one commit to another. I'll try to add more callers when I find time. I'm not convinced it's handling all the cases correctly, but we should have a generic function for this kind of operation, so I think it belongs somewhere in core (not in the uncommit extension). Differential Revision: https://phab.mercurial-scm.org/D6119
Mon, 11 Mar 2019 09:20:26 -0700 copies: remove dependency on scmutil by directly using match.exact()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 11 Mar 2019 09:20:26 -0700] rev 41936
copies: remove dependency on scmutil by directly using match.exact() I want to add a dependency from scmutil.copies(), so I need to remove this dependency first. Differential Revision: https://phab.mercurial-scm.org/D6118
Mon, 11 Mar 2019 09:35:36 -0700 uncommit: convert _fixdirstate() into _movedirstate()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 11 Mar 2019 09:35:36 -0700] rev 41935
uncommit: convert _fixdirstate() into _movedirstate() _fixdirstate() already also updates to the given commit, so let's rename it to _movedirstate(). Also update the documentation and drop the unnecessary "curctx" argument, since that should always be repo['.']. Differential Revision: https://phab.mercurial-scm.org/D6117
Mon, 11 Mar 2019 02:34:12 +0100 updatecaches: also warm the tags caches
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 11 Mar 2019 02:34:12 +0100] rev 41934
updatecaches: also warm the tags caches Resolving any name requires the tags cache to be warm. We make sure that `hg debugupdatecache` warm the tag cache entry too.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -28 +28 +50 +100 +300 +1000 +3000 +10000 tip