Tue, 08 Jun 2021 02:06:45 +0200 clone: reuse the stream clone logic for local clone
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 08 Jun 2021 02:06:45 +0200] rev 47453
clone: reuse the stream clone logic for local clone Streaming clone and local (non `--pull`) clone do mostly the same thing, however they were using different logic to do so. This means the logic frequently went out of sync and that new case had to be dealt with twice. This is fragile and anoying. So we replace this with a re-use of the logic we use for streaming clone. I can see various test changes: - a more precise progress output, - armless fncache loading during clone, - fncache is no longer hardlinked (since we write it by hand). I am not reinstalling the `reposimplestore` specific output, as far as I understand this variant have been broken for years. Differential Revision: https://phab.mercurial-scm.org/D10855
Wed, 09 Jun 2021 15:33:58 +0200 copyfiles: add a way to relax the file system checking for hardlink
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 09 Jun 2021 15:33:58 +0200] rev 47452
copyfiles: add a way to relax the file system checking for hardlink This is critical for transaction file, less for hardlink/copy clone as we are about to do. Since `pure` build does not have a `getfstype` implementation this would disable hardlink clone for all pure build. So we add a parameter to control that extra check. Differential Revision: https://phab.mercurial-scm.org/D10854
Tue, 08 Jun 2021 02:31:17 +0200 copyfile: add a option callback for failed hardlinking
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 08 Jun 2021 02:31:17 +0200] rev 47451
copyfile: add a option callback for failed hardlinking Local clone, adjust its UI depending on the success of using hardlinking, so we add a small callback making it possible for `copyfile` to signal if the requested hardlinking failed. Differential Revision: https://phab.mercurial-scm.org/D10853
Tue, 08 Jun 2021 02:06:02 +0200 streamingclone: extract the scanning part from the generation part
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 08 Jun 2021 02:06:02 +0200] rev 47450
streamingclone: extract the scanning part from the generation part We will reuse the scanning part for local clone, so we need it in a dedicated function. Differential Revision: https://phab.mercurial-scm.org/D10852
Tue, 08 Jun 2021 02:05:05 +0200 vfs: add a `register_file` method on the vfs class
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 08 Jun 2021 02:05:05 +0200] rev 47449
vfs: add a `register_file` method on the vfs class This is used by the fncache vfs to register new file. Until now, `fncache` have been doing this "automatically" by monitoring write pattern. However this is fragile and when we copy files in place by other means, we need something more robuts. So we add an explicit method to do so. Differential Revision: https://phab.mercurial-scm.org/D10851
Wed, 09 Jun 2021 01:10:34 +0200 clone: use "official" API to create local clone destination
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 09 Jun 2021 01:10:34 +0200] rev 47448
clone: use "official" API to create local clone destination This make sure we have a properly created, fully functional repository early. This will be useful to simply the hardlink/copy phases of the local clone to make it share more of its logic with the similar "stream" cloning. This has a minor impact of the test and the resulting repository has is better initialized (eg: the `wcache` directory is pre-created.) Differential Revision: https://phab.mercurial-scm.org/D10850
Wed, 09 Jun 2021 01:10:26 +0200 localrepo: introduce a clone_requirements function
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 09 Jun 2021 01:10:26 +0200] rev 47447
localrepo: introduce a clone_requirements function This function take a source repository and return a relevant set of requirements that should be used by a copy clone. This will help make the creation of the destination repository during copy clone simpler. Differential Revision: https://phab.mercurial-scm.org/D10849
Mon, 07 Jun 2021 20:40:43 +0200 createrepository: allow to directly pass the target requirements
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 07 Jun 2021 20:40:43 +0200] rev 47446
createrepository: allow to directly pass the target requirements This is useful when doing a local clone that copies store contents, it will requires the destination to use the very same store requirements so directly providing them will be simpler and safer Differential Revision: https://phab.mercurial-scm.org/D10848
Fri, 18 Jun 2021 16:03:42 -0700 narrowbundle: use new context manager for silencing the ui
Martin von Zweigbergk <martinvonz@google.com> [Fri, 18 Jun 2021 16:03:42 -0700] rev 47445
narrowbundle: use new context manager for silencing the ui Same reasoning as the previous change. This affects a few tests because of the hack from d7304434390f (changegroup: move message about added changes to transaction summary, 2019-09-08). Differential Revision: https://phab.mercurial-scm.org/D10886
Fri, 18 Jun 2021 16:00:58 -0700 debugbackupbundle: use new context manager for silencing the ui
Martin von Zweigbergk <martinvonz@google.com> [Fri, 18 Jun 2021 16:00:58 -0700] rev 47444
debugbackupbundle: use new context manager for silencing the ui A difference between setting `ui.quiet` and using `ui.silent()` is that the latter also silences `ui.write()` calls. That's practically always what one wants, including here, I think. Differential Revision: https://phab.mercurial-scm.org/D10885
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 tip