Mon, 27 Aug 2018 14:08:18 +0300 tests: add flat manifest case in test-narrow-widen-non-ellipsis.t
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 27 Aug 2018 14:08:18 +0300] rev 39358
tests: add flat manifest case in test-narrow-widen-non-ellipsis.t We had this test with tree manifest only because the tests were broken and we were fixing them and maintaing two different cases of broken tests was bit hard. Now that things work fine, let's add the flat manifest case. The test shows that things work fine in both cases. Differential Revision: https://phab.mercurial-scm.org/D4385
Mon, 27 Aug 2018 14:02:48 +0300 narrow: update the narrowspecs to new ones after pulling when widening
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 27 Aug 2018 14:02:48 +0300] rev 39357
narrow: update the narrowspecs to new ones after pulling when widening The ellipsis case updates the new narrowspecs at bundle2 handling code, and non-ellipsis widening didn't use to work and never set the new narrowpats. Previous pacth added server side logic for widening without ellipsis. This patch adds the missing repo.setnarrowpats() so that we set the new narrowpats after widening in non-ellipsis cases also. This makes widening with non-ellipsis case work but there are certain things which we can improve. Differential Revision: https://phab.mercurial-scm.org/D4384
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
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip