Sun, 26 Aug 2018 20:20:34 +0300 narrow: add server logic to send cg while widening without ellipsis
Pulkit Goyal <pulkit@yandex-team.ru> [Sun, 26 Aug 2018 20:20:34 +0300] rev 39356
narrow: add server logic to send cg while widening without ellipsis Before this patch, if you try to widen a narrow clone without ellipsis enabled, it will be broken and the exchange.pull() done by tracked command to widen the clone will be no-op because no custom logic exists for this and server sees that we have all csets and it says `no changes found`. The widening with ellipsis send KILL for existing changegroups and send new changegroups because of the change in ellipsis hash, but we can prevent that in non-ellipsis cases. This patch adds server side logic to send the changegroups for the changesets which are on the client again with filelogs and manifests for the new includes. This is a very starting implementation and we send changegroups and manifests too while we can prevent them. Following things can definitely be improved in the logic this patch adds: 1) Send just the filelogs and treemanifests 2) Send the filelogs only for the additions in the include I tried 1) here but the code is coupled tightly and the way I was able to do that was hacking into the changegroup generation code in a very dirty way, like adding conditionals and preventing the yield. This patch also adds a 'widen' kwarg to prevent other commands except widening to go through that codepath. The test changes demonstrate that the new implementation is correct and fixes things. Differential Revision: https://phab.mercurial-scm.org/D4383
Mon, 27 Aug 2018 13:30:08 +0300 tests: add test to show widening is broken without ellipsis
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 27 Aug 2018 13:30:08 +0300] rev 39355
tests: add test to show widening is broken without ellipsis This patch adds a test to show that widening a narrow clone is broken if ellipsis is disabled. I don't think I can add cases to existing test-narrow-widen.t and check-in a failing version of that. So I created a copy. Once the test is fixed, we can merge this new test file back into the original one using testcases. Also, this is just testing treemanifest case because having two cases and both or are failing with different outputs is a bit hard to manage. This is important because upcoming patches will try to fix the broken part. Differential Revision: https://phab.mercurial-scm.org/D4382
Mon, 27 Aug 2018 09:05:56 -0700 stringutil: emit multiple chunks when pretty printing
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 27 Aug 2018 09:05:56 -0700] rev 39354
stringutil: emit multiple chunks when pretty printing This avoids concatenating output inside pprintgen() itself. But the real reason for this is it will make it easier to add indentation, as we'll need to account for indentation when emitting each individual object in a collection. The verbosity of this code compared to the original is a bit unfortunate. But I suppose this is the price to pay for having nice things (streaming and indenting). We could probably abstract the "print a collection" bits into a generic function to avoid some duplication. But I'm not overly inclined to do this. Differential Revision: https://phab.mercurial-scm.org/D4398
Mon, 27 Aug 2018 09:02:39 -0700 stringutil: refactor core of pprint so it emits chunks
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 27 Aug 2018 09:02:39 -0700] rev 39353
stringutil: refactor core of pprint so it emits chunks This commit splits the core of pprint() to a new function that is a generator of chunks instead of a function returning a single value. This will make it possible to stream output without waiting for all data to be formatted first. And it will make it easier to implement support for indenting. Differential Revision: https://phab.mercurial-scm.org/D4397
Wed, 25 Jul 2018 13:28:36 -0400 contrib: import the relnotes script from the release-tools repo
Augie Fackler <augie@google.com> [Wed, 25 Jul 2018 13:28:36 -0400] rev 39352
contrib: import the relnotes script from the release-tools repo I figure this makes more sense to keep in the main repo, as it's a guide of sorts on how to use the releasenotes extension in the presence of commits that don't get relnotes annotations. Ported to Python 3, cleaned up some logic in a few places, but for the most part it's what we've been using for years. Differential Revision: https://phab.mercurial-scm.org/D4291
Wed, 25 Jul 2018 13:45:28 -0400 hghave: move from requiring the PYTHON3 env var to looking for `python3`
Augie Fackler <augie@google.com> [Wed, 25 Jul 2018 13:45:28 -0400] rev 39351
hghave: move from requiring the PYTHON3 env var to looking for `python3` We're starting to write new utility scripts in Python 3, and I think it's reasonable to expect `python3` to be something we should use if it's present. I wrote the regex to specifically ban Python 3 prior to Python 3.5 because we won't ever support that. I moved the only test that was using $PYTHON3 to just using `python3` directly. Differential Revision: https://phab.mercurial-scm.org/D4290
Wed, 29 Aug 2018 09:59:08 -0700 rename: return error status if any rename/copy failed
Martin von Zweigbergk <martinvonz@google.com> [Wed, 29 Aug 2018 09:59:08 -0700] rev 39350
rename: return error status if any rename/copy failed Ever since 447ea621e50e (copy: propagate errors properly, 2007-12-06), we have returned an error status if the source file did not exist. That commit did not return error status for any other errors, and it's unclear if that was on purpose or not. It seems to me like we should return an error in the other cases to, so that's what this patch does. Differential Revision: https://phab.mercurial-scm.org/D4419
Wed, 29 Aug 2018 09:54:50 -0700 rename: emit hint about using --after consistently
Martin von Zweigbergk <martinvonz@google.com> [Wed, 29 Aug 2018 09:54:50 -0700] rev 39349
rename: emit hint about using --after consistently Both the code and the message for the case where the source file was missing was inconsistent with the other similar messages. Differential Revision: https://phab.mercurial-scm.org/D4418
Wed, 29 Aug 2018 09:50:39 -0700 rename: quote hg commands in warnings
Martin von Zweigbergk <martinvonz@google.com> [Wed, 29 Aug 2018 09:50:39 -0700] rev 39348
rename: quote hg commands in warnings I think we usally use single quotes around hg commands in messages. Differential Revision: https://phab.mercurial-scm.org/D4417
Tue, 21 Aug 2018 21:05:01 +0800 zsh_completion: complete hg files
Anton Shestakov <av6@dwimlabs.net> [Tue, 21 Aug 2018 21:05:01 +0800] rev 39347
zsh_completion: complete hg files Differential Revision: https://phab.mercurial-scm.org/D4361
Tue, 21 Aug 2018 14:49:02 +0800 zsh_completion: adjust usage of common options
Anton Shestakov <av6@dwimlabs.net> [Tue, 21 Aug 2018 14:49:02 +0800] rev 39346
zsh_completion: adjust usage of common options addremove, remove and serve accept -S/--subrepos, and purge actually doesn't. qnew accepts -I/--include and -X/--exclude. qrefresh accepts -D/--currentdate, -U/--currentuser, -d/--date and -u/--user. rebase accepts -n/--dry-run. Differential Revision: https://phab.mercurial-scm.org/D4360
Sun, 26 Aug 2018 15:23:03 -0400 resolve: make condition clearer, and able to handle a new flag
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sun, 26 Aug 2018 15:23:03 -0400] rev 39345
resolve: make condition clearer, and able to handle a new flag Differential Revision: https://phab.mercurial-scm.org/D4377
Wed, 06 Jun 2018 00:48:24 +0200 shelve: drop mention of obsshelve file
Boris Feld <boris.feld@octobus.net> [Wed, 06 Jun 2018 00:48:24 +0200] rev 39344
shelve: drop mention of obsshelve file Core shelve extension does not use obsolescence, we clean up this unused file before adding a new info file.
Tue, 29 May 2018 11:40:40 +0200 shelve: rename method for data write/read
Boris Feld <boris.feld@octobus.net> [Tue, 29 May 2018 11:40:40 +0200] rev 39343
shelve: rename method for data write/read There are no user of this code nor any code related to obsshelve in the extensions right now, so we rename the function before using them. Note: The shelvedfile looks a bit strange. We should probably refactor it, however, this is an adventure for another series.
Thu, 23 Aug 2018 00:51:38 +0200 shelve: move createcmd next to _docreatecmd
Boris Feld <boris.feld@octobus.net> [Thu, 23 Aug 2018 00:51:38 +0200] rev 39342
shelve: move createcmd next to _docreatecmd It is simpler not to have to jump around the file all the time.
Sun, 05 Aug 2018 13:34:04 +0900 minirst: filter blocks by full path to section
Yuya Nishihara <yuya@tcha.org> [Sun, 05 Aug 2018 13:34:04 +0900] rev 39341
minirst: filter blocks by full path to section
Sun, 05 Aug 2018 13:34:58 +0900 minirst: mark getsections() as an internal helper
Yuya Nishihara <yuya@tcha.org> [Sun, 05 Aug 2018 13:34:58 +0900] rev 39340
minirst: mark getsections() as an internal helper
Sun, 05 Aug 2018 12:42:10 +0900 help: rewrite parsing of help topic to not drop section name with dots
Yuya Nishihara <yuya@tcha.org> [Sun, 05 Aug 2018 12:42:10 +0900] rev 39339
help: rewrite parsing of help topic to not drop section name with dots A subtopic is no longer lowercased since it should be considered a part of a topic path, not a section filter.
Sun, 05 Aug 2018 12:48:02 +0900 test-help: add tests showing that sections can't be filtered by dotted name
Yuya Nishihara <yuya@tcha.org> [Sun, 05 Aug 2018 12:48:02 +0900] rev 39338
test-help: add tests showing that sections can't be filtered by dotted name
Sat, 18 Aug 2018 08:41:36 +0200 revlogdeltas: move finddeltainfo filtering inside _candidategroups
Boris Feld <boris.feld@octobus.net> [Sat, 18 Aug 2018 08:41:36 +0200] rev 39337
revlogdeltas: move finddeltainfo filtering inside _candidategroups Now all "simple" filtering logic is gathered in one place. The `finddeltainfo` method is more straightforward and the `_candidate_groups` function knows more about filtering revisions before we compute a delta against them.
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 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip