Thu, 23 May 2019 22:50:11 -0400 manifest: add some documentation to _lazymanifest python code stable 5.0.1
Matt Harbison <matt_harbison@yahoo.com> [Thu, 23 May 2019 22:50:11 -0400] rev 42378
manifest: add some documentation to _lazymanifest python code It was not particularly easy figuring out the design of this class and keeping track of how the pieces work. So might as well write some of it down for the next person.
Thu, 23 May 2019 21:54:24 -0400 manifest: avoid corruption by dropping removed files with pure (issue5801) stable
Matt Harbison <matt_harbison@yahoo.com> [Thu, 23 May 2019 21:54:24 -0400] rev 42377
manifest: avoid corruption by dropping removed files with pure (issue5801) Previously, removed files would simply be marked by overwriting the first byte with NUL and dropping their entry in `self.position`. But no effort was made to ignore them when compacting the dictionary into text form. This allowed them to slip into the manifest revision, since the code seems to be trying to minimize the string operations by copying as large a chunk as possible. As part of this, compact() walks the existing text based on entries in the `positions` list, and consumed everything up to the next position entry. This typically resulted in a ValueError complaining about unsorted manifest entries. Sometimes it seems that files do get dropped in large repos- it seems to correspond to there being a new entry that would take the same slot. A much more trivial problem is that if the only changes were removals, `_compact()` didn't even run because `__delitem__` doesn't add anything to `self.extradata`. Now there's an explicit variable to flag this, both to allow `_compact()` to run, and to avoid searching the manifest in cases where there are no removals. In practice, this behavior was mostly obscured by the check in fastdelta() which takes a different path that explicitly drops removed files if there are fewer than 1000 changes. However, timeless has a repo where after rebasing tens of commits, a totally different path[1] is taken that bypasses the change count check and hits this problem. [1] https://www.mercurial-scm.org/repo/hg/file/2338bdea4474/mercurial/manifest.py#l1511
Thu, 23 May 2019 21:39:19 -0400 tests: demonstrate broken manifest generation with the pure module stable
Matt Harbison <matt_harbison@yahoo.com> [Thu, 23 May 2019 21:39:19 -0400] rev 42376
tests: demonstrate broken manifest generation with the pure module This will be fixed next. But I don't fully understand how 'b.txt' is actually removed properly in the second test, given what's broken. Also, I'm not sure why 'bb.txt' is flagged as not being in the manifest, when it clearly appears to be.
Sat, 11 May 2019 00:06:06 -0700 tests: add test for {file_mods}, {file_adds}, {file_dels} on merge commit
Martin von Zweigbergk <martinvonz@google.com> [Sat, 11 May 2019 00:06:06 -0700] rev 42375
tests: add test for {file_mods}, {file_adds}, {file_dels} on merge commit Differential Revision: https://phab.mercurial-scm.org/D6368
Thu, 18 Apr 2019 13:34:20 -0700 context: add ctx.files{modified,added,removed}() methods
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 Apr 2019 13:34:20 -0700] rev 42374
context: add ctx.files{modified,added,removed}() methods Changeset-centric copy tracing is currently very slow because it often reads manifests. One place it needs the manifest is in _chain(), where it removes a copy X->Y if Y has subsequently gotten removed. I want to speed that up by keeping track directly in the changeset of which files are removed in the changeset. These methods will be similar to ctx.p[12]copies() in that way: they will either read from the changeset or calculate the information from the manifests otherwise. Note that these are different from ctx.{modified,added,removed}() on merge commits. Those functions always compare to p1, but the new ones compare to both parents. filesadded() means "file does not exist in either parent but exists now", filesremoved() means "file existed in either parent but does not exist now", and filesmodified() means "file existed in either parent and still exists". The set of files in ctx.files() is the union of the files from the three new functions (and the three new ones are all disjoint sets). Also note that uncommitted merges are weird as usual. The invariant mentioned above still holds, but the functions compare to p1 (and are thus identical to the existing methods). Differential Revision: https://phab.mercurial-scm.org/D6367
Thu, 09 May 2019 15:09:07 -0700 copies: split up _chain() in naive chaining and filtering steps
Martin von Zweigbergk <martinvonz@google.com> [Thu, 09 May 2019 15:09:07 -0700] rev 42373
copies: split up _chain() in naive chaining and filtering steps The function now has two clearly defined steps. The first step is the actual chaining. This step is very cheap. The second step is filtering out invalid copies. This step is expensive. For changeset-centric copy tracing, I want to do the filtering step only at the end. This patch prepares for that. Differential Revision: https://phab.mercurial-scm.org/D6418
Fri, 24 May 2019 09:24:47 -0700 relnotes: document changed behavior of ui.origbackuppath pointing to file
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 May 2019 09:24:47 -0700] rev 42372
relnotes: document changed behavior of ui.origbackuppath pointing to file Differential Revision: https://phab.mercurial-scm.org/D6446
Sat, 11 May 2019 00:17:42 -0700 templatekw: move showfileadds() close to showfile{mods,dels}()
Martin von Zweigbergk <martinvonz@google.com> [Sat, 11 May 2019 00:17:42 -0700] rev 42371
templatekw: move showfileadds() close to showfile{mods,dels}() Differential Revision: https://phab.mercurial-scm.org/D6370
Fri, 24 May 2019 15:38:50 +0300 py3: use range() instead of xrange()
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 24 May 2019 15:38:50 +0300] rev 42370
py3: use range() instead of xrange() The latter does not exist on Python 3. This makes test-contrib-perf.t pass on Python 3 again. Differential Revision: https://phab.mercurial-scm.org/D6443
Fri, 24 May 2019 15:59:59 +0300 narrow: move heads close to common as they are closely related
Pulkit Goyal <pulkit@yandex-team.ru> [Fri, 24 May 2019 15:59:59 +0300] rev 42369
narrow: move heads close to common as they are closely related Differential Revision: https://phab.mercurial-scm.org/D6445
Fri, 24 May 2019 15:57:00 +0300 narrow: pass binary nodeids to generateellipsesbundle2()
Pulkit Goyal <pulkit@yandex-team.ru> [Fri, 24 May 2019 15:57:00 +0300] rev 42368
narrow: pass binary nodeids to generateellipsesbundle2() We generally work with binary nodeids and it's should be expected that new function gets the nodeids in binary form already. Differential Revision: https://phab.mercurial-scm.org/D6444
Fri, 24 May 2019 12:33:46 +0200 match: stabilize _rootsdirsandparents doctest
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 24 May 2019 12:33:46 +0200] rev 42367
match: stabilize _rootsdirsandparents doctest Changeset c4b8f8637d7a tried to stabilize some matcher test by using a set. This did not work because the set order is not stable. To fix it, we post process the result to display a sorted version of the set.
Tue, 21 May 2019 05:32:14 +0530 narrow: factor out logic to build ellipses related b2parts in separate fn
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 21 May 2019 05:32:14 +0530] rev 42366
narrow: factor out logic to build ellipses related b2parts in separate fn This will help us switch more cleanly to using wireprotocol commands instead of using exchange.pull() which exchanges more things then required. Differential Revision: https://phab.mercurial-scm.org/D6435
Tue, 21 May 2019 04:49:18 +0530 narrow: remove unrequired compat code for old versions of hg
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 21 May 2019 04:49:18 +0530] rev 42365
narrow: remove unrequired compat code for old versions of hg As the comment says, that if is only required for servers having hg version 3.1 and 3.2. Any client connecting having hg 3.1 or 3.2 locally and trying to use narrow should already be broken taking in account the changes which have been done since narrow moved to core. Differential Revision: https://phab.mercurial-scm.org/D6434
Thu, 23 May 2019 19:05:39 +0200 perf: make sure to explicitly disable any profiler after the first iteration
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 23 May 2019 19:05:39 +0200] rev 42364
perf: make sure to explicitly disable any profiler after the first iteration The current code work, because of some edge behavior of the `profile` class. We make it explicit that the profiler is not in effect more than once.
(0) -30000 -10000 -3000 -1000 -300 -100 -15 +15 +100 +300 +1000 +3000 tip