Tue, 02 Jun 2020 21:39:07 +0900 simplemerge: fix function name that tests if ctx is not null revision
Yuya Nishihara <yuya@tcha.org> [Tue, 02 Jun 2020 21:39:07 +0900] rev 44947
simplemerge: fix function name that tests if ctx is not null revision
Tue, 09 Jun 2020 13:18:21 -0700 git: decode node IDs back into Python strings (issue6349)
Hollis Blanchard <hollis_blanchard@mentor.com> [Tue, 09 Jun 2020 13:18:21 -0700] rev 44946
git: decode node IDs back into Python strings (issue6349) db.text_factory = bytes, so the database contains only strings. The object IDs we get from pygit2 are Python strings. b'foo' != 'foo' This change allows the "don't reindex" optimization to work by allowing the "cur_cache_heads == cache_heads" comparison a few lines down to succeed. Differential Revision: https://phab.mercurial-scm.org/D8622
Tue, 09 Jun 2020 22:02:09 +0530 phabricator: make it clear what happen when no response
Sushil khanchi <sushilkhanchi97@gmail.com> [Tue, 09 Jun 2020 22:02:09 +0530] rev 44945
phabricator: make it clear what happen when no response Differential Revision: https://phab.mercurial-scm.org/D8621
Mon, 08 Jun 2020 11:43:07 +0530 tests: make it clear what happen when no response entered
Sushil khanchi <sushilkhanchi97@gmail.com> [Mon, 08 Jun 2020 11:43:07 +0530] rev 44944
tests: make it clear what happen when no response entered Differential Revision: https://phab.mercurial-scm.org/D8620
Sat, 18 Jan 2020 10:07:07 -0800 localrepo: handle ValueError during repository opening
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 18 Jan 2020 10:07:07 -0800] rev 44943
localrepo: handle ValueError during repository opening Python 3.8 can raise ValueError on attempt of an I/O operation against an illegal path. This was causing test-remotefilelog-gc.t to fail on Python 3.8. This commit teaches repository opening to handle ValueError and re-raise an Abort on failure. An arguably better solution would be to implement this logic in the vfs layer. But that seems like a bag of worms and I don't want to go down that rabbit hole. Until users report uncaught ValueError exceptions in the wild, I think it is fine to patch this at the only occurrence our test harness is finding it. Differential Revision: https://phab.mercurial-scm.org/D7944
Wed, 27 May 2020 12:56:13 +0200 metadata: filter the `removed` set to only contains relevant data
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 27 May 2020 12:56:13 +0200] rev 44942
metadata: filter the `removed` set to only contains relevant data The `files` entry can be bogus and contains too many entries. This can badly combines with the computation of `removed` inflating the set size. The can lead to the changesets centric rename computation to process much more data than needed, slowing it down (and increasing space taken by data storage). In practice newer commits already that reduced set, this applies this "fix" to older changeset. Differential Revision: https://phab.mercurial-scm.org/D8589
Wed, 27 May 2020 12:45:39 +0200 files: extract code for extra filtering of the `removed` entry into copies
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 27 May 2020 12:45:39 +0200] rev 44941
files: extract code for extra filtering of the `removed` entry into copies We want to reduce the set of `removed` files that to the set of files actually removed. That `removed` set is used as of the changeset centric algorithm, having smaller sets means less processing and faster computation. In this changeset we extract the code to be a function of it own. We will make use of it in the next changesets. Differential Revision: https://phab.mercurial-scm.org/D8588
Wed, 27 May 2020 12:26:08 +0200 metadata: move computation related to files touched in a dedicated module
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 27 May 2020 12:26:08 +0200] rev 44940
metadata: move computation related to files touched in a dedicated module This was suggested by Yuya Nishihara a while back. Since I am about to add more metadata related computation, lets create a new repositories. Differential Revision: https://phab.mercurial-scm.org/D8587
Fri, 05 Jun 2020 11:10:33 -0700 merge: move an inspection of the dirstate from record to calculate phase
Martin von Zweigbergk <martinvonz@google.com> [Fri, 05 Jun 2020 11:10:33 -0700] rev 44939
merge: move an inspection of the dirstate from record to calculate phase The intent is clearly to have `calculateupdates()` figure out what actions need to be taken and `recordupdates()` to make necessary modifications to the dirstate. However, in the `ACTION_PATH_CONFLICT_RESOLVE` case, there was one little inspection of copy information done in `recordupdates()`. This patch moves that to `calculateupdates()`. That will help with the next patch, which makes `merge.update()` work better with `overlayworkingctx` (copies should be recorded there too, even though we skip the `recordupdates()` step). Differential Revision: https://phab.mercurial-scm.org/D8615
Sat, 06 Jun 2020 19:15:11 +0800 tests: adjust to the new format in pyflakes output
Anton Shestakov <av6@dwimlabs.net> [Sat, 06 Jun 2020 19:15:11 +0800] rev 44938
tests: adjust to the new format in pyflakes output According to the pyflakes' NEWS.rst, the default output format changed recently: 2.2.0 (2020-04-08) - Include column information in error messages So the lines now read: contrib/perf.py:149:15 undefined name 'xrange' mercurial/hgweb/server.py:427:13 undefined name 'reload' mercurial/util.py:2862:24 undefined name 'file' Differential Revision: https://phab.mercurial-scm.org/D8618
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 tip