Mon, 09 Oct 2017 15:13:41 +0200 revlog: ignore empty trailing chunks when reading segments
Paul Morelle <paul.morelle@octobus.net> [Mon, 09 Oct 2017 15:13:41 +0200] rev 34823
revlog: ignore empty trailing chunks when reading segments When a merge commit creates an empty diff in the revlog, its offset may still be quite far from the end of the previous chunk. Skipping these empty chunks may reduce read size significantly. In most cases, there is no gain, and in some cases, little gain. On my clone of pypy, `hg manifest` reads 65% less bytes (96140 i/o 275943) for revision 4260 by ignoring the only empty trailing diff. For revision 2229, 35% (34557 i/o 53435) Sadly, this is difficult to reproduce, as hg clone can make its own different structure every time.
Wed, 20 Sep 2017 19:17:37 +0200 phase: isolate logic to update remote phrase through bundle2 pushkey
Boris Feld <boris.feld@octobus.net> [Wed, 20 Sep 2017 19:17:37 +0200] rev 34822
phase: isolate logic to update remote phrase through bundle2 pushkey Move the logic to build bundle2 pushkey part into its dedicated function. It will help to keep the logic clear when adding support for sending phases change using 'phase-heads' part.
Wed, 11 Oct 2017 07:40:00 +0200 phase: generate a push-race detection part on push
Boris Feld <boris.feld@octobus.net> [Wed, 11 Oct 2017 07:40:00 +0200] rev 34821
phase: generate a push-race detection part on push We are about to switch phase pushing from using pushkey to using a the new dedicated binary part. We introduce the push race detection on its own to help detect potential impact.
Wed, 11 Oct 2017 07:13:02 +0200 phase: introduce a new 'check:phases' part
Boris Feld <boris.feld@octobus.net> [Wed, 11 Oct 2017 07:13:02 +0200] rev 34820
phase: introduce a new 'check:phases' part This part checks if revisions are still in the same phase as when the bundle was generated. This is similar to what 'check:heads' or 'check:updated-heads' bundle2 part achieves for changesets. We needs seems before we can move away from pushkey usage from phase since pushkey has it own built-in push-race detection.
Wed, 11 Oct 2017 18:39:04 +0200 phase: gather remote phase information in a summary object
Boris Feld <boris.feld@octobus.net> [Wed, 11 Oct 2017 18:39:04 +0200] rev 34819
phase: gather remote phase information in a summary object We keep useful phase information around. The data will be reused with detecting push-race in later changesets.
Wed, 11 Oct 2017 18:39:34 +0200 phase: simplify the check for issue3781 shortcut in discovery
Boris Feld <boris.feld@octobus.net> [Wed, 11 Oct 2017 18:39:34 +0200] rev 34818
phase: simplify the check for issue3781 shortcut in discovery We'll rework the code around this check. Limiting the entanglement will help with later changesets
Mon, 16 Oct 2017 12:36:42 +0200 exchange: fix issue3781 reference in the comment
Boris Feld <boris.feld@octobus.net> [Mon, 16 Oct 2017 12:36:42 +0200] rev 34817
exchange: fix issue3781 reference in the comment This comment is about: issue3781: Courtesy Phases synchronisation to publishing server prevent subrepo push Not about: issue3871: Slow hg log when template contains {file_adds}, {file_mods} and {file_dels}
Wed, 11 Oct 2017 20:08:02 +0200 phase: filter out non-draft item in "draft root"
Boris Feld <boris.feld@octobus.net> [Wed, 11 Oct 2017 20:08:02 +0200] rev 34816
phase: filter out non-draft item in "draft root" The on-disk file can contain draft root that are descendants of secret root. The resulting phase computation is correct, but the phases root content is not. I will send another series to introduce code that remove some of the cases where this can happens, but we first need to damage control the existing case. After this changeset, we can no longer advertise secret changeset as draft root.
Sun, 15 Oct 2017 22:48:02 -0400 subrepo: share instead of clone if the parent repo is shared (issue5675) (BC)
Matt Harbison <matt_harbison@yahoo.com> [Sun, 15 Oct 2017 22:48:02 -0400] rev 34815
subrepo: share instead of clone if the parent repo is shared (issue5675) (BC) Previously, only the top level repo was shared, and then any subrepos were cloned on demand. This is problematic because commits to the parent repo would write an updated .hgsubstate to the share source, but the corresponding subrepo commit would be stuck in the local subrepo. That would prevent an update in the source repo. We already go to great lengths to avoid having inconsistent repos (e.g., `hg push -r rev` will push _everything_ in a subrepo, even if it isn't referenced in one of the parent's outgoing commits). Therefore, this seems like a bug fix, and there's no option to get the old behavior. I can't imagine the previous behavior was useful to anybody. There shouldn't be an issue with svn, since it is centralized. Maybe --git-dir can be used for git subrepos, but I'll leave that to someone more familiar with git. An integer was previously being implicitly returned from commands.share(), which caused dispatch() to start crashing when changing over to returning the shared repo. All error paths appear to raise, so this can be hardcoded to success. The clone command checks for 'is None' in a similar pattern, but since hg.clone() always returns a tuple, that seems wrong? .. fix:: Issue 5675 Creating a share of a repository with a Mercurial subrepository will now share the subrepository. and .. bc:: Mercurial subrepositories are now shared instead of cloned when the parent repository is shared. This prevents dangling subrepository references in the share source. Previously shared repositories with cloned subrepositories will continue to function unchanged.
Sun, 15 Oct 2017 16:57:34 -0400 tests: update output for no-symlink platforms
Matt Harbison <matt_harbison@yahoo.com> [Sun, 15 Oct 2017 16:57:34 -0400] rev 34814
tests: update output for no-symlink platforms This goes with eb586ed5d8ce.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip