Wed, 29 Aug 2018 09:55:11 -0700 revlogdeltas: split candidate groups selection from the filtering logic
Boris Feld <boris.feld@octobus.net> [Wed, 29 Aug 2018 09:55:11 -0700] rev 39336
revlogdeltas: split candidate groups selection from the filtering logic The group iteration has two main components: * walking candidates, the logic that we are about to extend to build intermediate snapshots, * Making sure we test diffs against interesting bases. No duplicated tests, skipping empty revisions, etc. We split `_candidategroups` to separate the two components. This achieves two goals: * It will be simpler to update the walking logic for intermediate snapshots, * We can gather the filtering logic from `finddeltainfo` into `_candidategroups` to centralize it.
Sat, 18 Aug 2018 07:32:05 +0200 revlogdeltas: pass revision number to _candidatesgroups
Boris Feld <boris.feld@octobus.net> [Sat, 18 Aug 2018 07:32:05 +0200] rev 39335
revlogdeltas: pass revision number to _candidatesgroups The `_candidates_groups` logic works on revisions, so the nodes are currently just converted to revs at the top of the function. It seems cleaner to instead pass revision numbers to the function. Having this conversion out of the way will help for further cleanups.
Sat, 18 Aug 2018 07:27:34 +0200 revlogdeltas: extract _getcandidaterevs in a function
Boris Feld <boris.feld@octobus.net> [Sat, 18 Aug 2018 07:27:34 +0200] rev 39334
revlogdeltas: extract _getcandidaterevs in a function The logic barely uses the object it is attached to. This is an important function that we will clean up in the coming changesets. Moving it at the top level helps us with that cleanup.
Thu, 16 Aug 2018 04:38:57 +0200 revlogdeltas: always return a delta info object in finddeltainfo
Boris Feld <boris.feld@octobus.net> [Thu, 16 Aug 2018 04:38:57 +0200] rev 39333
revlogdeltas: always return a delta info object in finddeltainfo Previously, the method returned `None` when a full snapshot was needed. The caller had to determine how to produce one itself. In practice, building a `_deltainfo` object for a full snapshot is simple. So we build it at the `finddeltainfo` level and always return a `_deltainfo` object. The caller can now simply process the `_deltainfo` return in all cases.
Thu, 16 Aug 2018 04:20:34 +0200 revlogdeltas: move special cases around raw revisions in finddeltainfo
Boris Feld <boris.feld@octobus.net> [Thu, 16 Aug 2018 04:20:34 +0200] rev 39332
revlogdeltas: move special cases around raw revisions in finddeltainfo The method already contains logic for no-diff cases. Having everything in the same place is more consistent and unlocks other code improvements.
Wed, 29 Aug 2018 09:41:04 -0700 revlogdeltas: extra fulltext building in its own function
Boris Feld <boris.feld@octobus.net> [Wed, 29 Aug 2018 09:41:04 -0700] rev 39331
revlogdeltas: extra fulltext building in its own function The process of building a full text from a delta is complex enough to deserve isolation. The previous function mixed cache management and computation, we now have clearer boundaries and simpler functions/methods.
Thu, 16 Aug 2018 02:53:42 +0200 revlog: split functionality related to deltas computation in a new module
Boris Feld <boris.feld@octobus.net> [Thu, 16 Aug 2018 02:53:42 +0200] rev 39330
revlog: split functionality related to deltas computation in a new module The revlog module is getting big and this logic is getting more and more advanced. Moving it to `mercurial.revlogutils.deltas` split a lot off revlog.py and will help this logic to become less interleaved with revlog. The code is simply moved without modification (but for namespace changes). Refactoring and improvement will be made in later changesets.
Thu, 16 Aug 2018 02:08:13 +0200 revlog: split constants into a new `revlogutils.constants` module
Boris Feld <boris.feld@octobus.net> [Thu, 16 Aug 2018 02:08:13 +0200] rev 39329
revlog: split constants into a new `revlogutils.constants` module We want to split some logic out of the main revlog file (the delta computing logic). However, this logic needs access to multiple constants related to the revlog. So we move all revlog related constants into a new module that could be imported from multiple places. We don't copy the file (preserving blame history) because there are only a few moving lines. Also, copying the file would result in annoying merge conflicts with ongoing work from others contributors.
Thu, 12 Jul 2018 12:11:20 -0700 rebase: skip extinct revisions even if it has no successor in rebase set
Martin von Zweigbergk <martinvonz@google.com> [Thu, 12 Jul 2018 12:11:20 -0700] rev 39328
rebase: skip extinct revisions even if it has no successor in rebase set Differential Revision: https://phab.mercurial-scm.org/D4408
Wed, 11 Jul 2018 12:26:44 -0700 tests: add test showing that rebase of extinct commit with successor fails
Martin von Zweigbergk <martinvonz@google.com> [Wed, 11 Jul 2018 12:26:44 -0700] rev 39327
tests: add test showing that rebase of extinct commit with successor fails As the test case shows, attempting to rebase a commit that has a successor that is not in the rebase set and not in the destination currently fails because it "will cause divergences". However, it doesn't seem like there's any harm in skipping the extinct commit. I suspect this case missed simply because extinct revisions are usually hidden. Differential Revision: https://phab.mercurial-scm.org/D4407
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip