sapling/tests/test-treemanifest-fastmanifest.t

78 lines
2.1 KiB
Perl
Raw Normal View History

treemanifest: improve integration with fastmanifest Summary: Previously treemanifest and fastmanifest were largely unaware of each other. If the fastmanifest was available, we'd use that. If not, we'd try tree. Then we'd fall back to flat. When comparing two manifests, this could cause problems since if one manifest was fast and one was tree, we'd have to fall all the way back to flat manifests to compare them. This patch adds the ability to build a treemanifest from a fastmanifest for inmemory manifests that were copied from a commit that has both a fastmanifest and a treemanifest. We do it by diff'ing the inmemory fastmanifest with the commit fastmanifest, then applying that diff to the commit's treemanifest. Then we can compare that tree with the other tree. This is particularly useful when doing things like 'hg up master' after a pull. The new master commit probably has a treemanifest, but doesn't yet have a fastmanifest, while the commit the user is on probably has both. Now we can do that hg up without having to parse a full manifest. Once treemanifest has been enabled, every commit (both pulled and user created) should have treemanifests. Therefore this case should never happen when comparing two normal commits. So in theory, the only way to hit this case is when Mercurial does a manifest.copy() on a manifest that has a fastmanifest (like when reading a workingctx which must copy the commit manifest and apply working copy changes), since the copy will choose to copy the fastmanifest and leave the treemanifest behind. This patch addresses that case, so I think there shouldn't be other cases. Test Plan: Adds a test that covers this case. Reviewers: #mercurial, rmcelroy Reviewed By: rmcelroy Subscribers: rmcelroy, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4402604 Signature: t1:4402604:1484216866:1c075f314026aaf608095b4aca37c9a4277ababa
2017-01-12 23:26:21 +03:00
# Integration tests between tree and fastmanifest
$ . "$TESTDIR/library.sh"
$ PYTHONPATH=$TESTDIR/..:$PYTHONPATH
$ export PYTHONPATH
$ cat >> $TESTTMP/flatcheck.py <<EOF
> import sys, traceback
> from mercurial import extensions, manifest
> def uisetup(ui):
> extensions.wrapfunction(manifest.manifestrevlog, 'revision', readmf)
> def readmf(orig, self, nodeorrev, **kwargs):
> if nodeorrev != -1:
> print >> sys.stderr, 'read flat manifest'
> stack = traceback.extract_stack()
> print >> sys.stderr, ''.join(traceback.format_list(stack[-3:-2]))
> return orig(self, nodeorrev, **kwargs)
> EOF
$ hg init master
$ cd master
$ echo a > a && hg ci -Aqm 'added a'
$ cd ..
$ hg clone -q ssh://user@dummy/master client
$ cd master
$ echo b > b && hg ci -Aqm 'added b'
$ echo c > c && hg ci -Aqm 'added c'
$ cd ..
$ cd client
$ cat >> .hg/hgrc <<EOF
> [extensions]
> fastmanifest=$TESTDIR/../fastmanifest
treemanifest: improve integration with fastmanifest Summary: Previously treemanifest and fastmanifest were largely unaware of each other. If the fastmanifest was available, we'd use that. If not, we'd try tree. Then we'd fall back to flat. When comparing two manifests, this could cause problems since if one manifest was fast and one was tree, we'd have to fall all the way back to flat manifests to compare them. This patch adds the ability to build a treemanifest from a fastmanifest for inmemory manifests that were copied from a commit that has both a fastmanifest and a treemanifest. We do it by diff'ing the inmemory fastmanifest with the commit fastmanifest, then applying that diff to the commit's treemanifest. Then we can compare that tree with the other tree. This is particularly useful when doing things like 'hg up master' after a pull. The new master commit probably has a treemanifest, but doesn't yet have a fastmanifest, while the commit the user is on probably has both. Now we can do that hg up without having to parse a full manifest. Once treemanifest has been enabled, every commit (both pulled and user created) should have treemanifests. Therefore this case should never happen when comparing two normal commits. So in theory, the only way to hit this case is when Mercurial does a manifest.copy() on a manifest that has a fastmanifest (like when reading a workingctx which must copy the commit manifest and apply working copy changes), since the copy will choose to copy the fastmanifest and leave the treemanifest behind. This patch addresses that case, so I think there shouldn't be other cases. Test Plan: Adds a test that covers this case. Reviewers: #mercurial, rmcelroy Reviewed By: rmcelroy Subscribers: rmcelroy, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4402604 Signature: t1:4402604:1484216866:1c075f314026aaf608095b4aca37c9a4277ababa
2017-01-12 23:26:21 +03:00
> flatcheck=$TESTTMP/flatcheck.py
> treemanifest=$TESTDIR/../treemanifest
>
> [remotefilelog]
> usefastdatapack=True
> reponame=master
>
> [fastmanifest]
> usetree=True
> usecache=True
>
> [treemanifest]
> autocreatetrees=True
> demanddownload=False
treemanifest: improve integration with fastmanifest Summary: Previously treemanifest and fastmanifest were largely unaware of each other. If the fastmanifest was available, we'd use that. If not, we'd try tree. Then we'd fall back to flat. When comparing two manifests, this could cause problems since if one manifest was fast and one was tree, we'd have to fall all the way back to flat manifests to compare them. This patch adds the ability to build a treemanifest from a fastmanifest for inmemory manifests that were copied from a commit that has both a fastmanifest and a treemanifest. We do it by diff'ing the inmemory fastmanifest with the commit fastmanifest, then applying that diff to the commit's treemanifest. Then we can compare that tree with the other tree. This is particularly useful when doing things like 'hg up master' after a pull. The new master commit probably has a treemanifest, but doesn't yet have a fastmanifest, while the commit the user is on probably has both. Now we can do that hg up without having to parse a full manifest. Once treemanifest has been enabled, every commit (both pulled and user created) should have treemanifests. Therefore this case should never happen when comparing two normal commits. So in theory, the only way to hit this case is when Mercurial does a manifest.copy() on a manifest that has a fastmanifest (like when reading a workingctx which must copy the commit manifest and apply working copy changes), since the copy will choose to copy the fastmanifest and leave the treemanifest behind. This patch addresses that case, so I think there shouldn't be other cases. Test Plan: Adds a test that covers this case. Reviewers: #mercurial, rmcelroy Reviewed By: rmcelroy Subscribers: rmcelroy, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4402604 Signature: t1:4402604:1484216866:1c075f314026aaf608095b4aca37c9a4277ababa
2017-01-12 23:26:21 +03:00
> EOF
$ hg pull -q
read flat manifest
File "*fastmanifest/implementation.py", line *, in loadflat (glob)
treemanifest: improve integration with fastmanifest Summary: Previously treemanifest and fastmanifest were largely unaware of each other. If the fastmanifest was available, we'd use that. If not, we'd try tree. Then we'd fall back to flat. When comparing two manifests, this could cause problems since if one manifest was fast and one was tree, we'd have to fall all the way back to flat manifests to compare them. This patch adds the ability to build a treemanifest from a fastmanifest for inmemory manifests that were copied from a commit that has both a fastmanifest and a treemanifest. We do it by diff'ing the inmemory fastmanifest with the commit fastmanifest, then applying that diff to the commit's treemanifest. Then we can compare that tree with the other tree. This is particularly useful when doing things like 'hg up master' after a pull. The new master commit probably has a treemanifest, but doesn't yet have a fastmanifest, while the commit the user is on probably has both. Now we can do that hg up without having to parse a full manifest. Once treemanifest has been enabled, every commit (both pulled and user created) should have treemanifests. Therefore this case should never happen when comparing two normal commits. So in theory, the only way to hit this case is when Mercurial does a manifest.copy() on a manifest that has a fastmanifest (like when reading a workingctx which must copy the commit manifest and apply working copy changes), since the copy will choose to copy the fastmanifest and leave the treemanifest behind. This patch addresses that case, so I think there shouldn't be other cases. Test Plan: Adds a test that covers this case. Reviewers: #mercurial, rmcelroy Reviewed By: rmcelroy Subscribers: rmcelroy, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4402604 Signature: t1:4402604:1484216866:1c075f314026aaf608095b4aca37c9a4277ababa
2017-01-12 23:26:21 +03:00
data = self._revlog.revision(self._node)
# Test checking out from a fastmanifest to a treemanifest uses the treemanifest
$ hg up tip
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ echo d > d && hg ci -Aqm 'added d'
read flat manifest
File "*fastmanifest/implementation.py", line *, in add (glob)
treemanifest: improve integration with fastmanifest Summary: Previously treemanifest and fastmanifest were largely unaware of each other. If the fastmanifest was available, we'd use that. If not, we'd try tree. Then we'd fall back to flat. When comparing two manifests, this could cause problems since if one manifest was fast and one was tree, we'd have to fall all the way back to flat manifests to compare them. This patch adds the ability to build a treemanifest from a fastmanifest for inmemory manifests that were copied from a commit that has both a fastmanifest and a treemanifest. We do it by diff'ing the inmemory fastmanifest with the commit fastmanifest, then applying that diff to the commit's treemanifest. Then we can compare that tree with the other tree. This is particularly useful when doing things like 'hg up master' after a pull. The new master commit probably has a treemanifest, but doesn't yet have a fastmanifest, while the commit the user is on probably has both. Now we can do that hg up without having to parse a full manifest. Once treemanifest has been enabled, every commit (both pulled and user created) should have treemanifests. Therefore this case should never happen when comparing two normal commits. So in theory, the only way to hit this case is when Mercurial does a manifest.copy() on a manifest that has a fastmanifest (like when reading a workingctx which must copy the commit manifest and apply working copy changes), since the copy will choose to copy the fastmanifest and leave the treemanifest behind. This patch addresses that case, so I think there shouldn't be other cases. Test Plan: Adds a test that covers this case. Reviewers: #mercurial, rmcelroy Reviewed By: rmcelroy Subscribers: rmcelroy, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4402604 Signature: t1:4402604:1484216866:1c075f314026aaf608095b4aca37c9a4277ababa
2017-01-12 23:26:21 +03:00
p1text = origself.revision(p1)
$ hg debugcachemanifest -r .
read flat manifest
File "*fastmanifest/implementation.py", line *, in loadflat (glob)
treemanifest: improve integration with fastmanifest Summary: Previously treemanifest and fastmanifest were largely unaware of each other. If the fastmanifest was available, we'd use that. If not, we'd try tree. Then we'd fall back to flat. When comparing two manifests, this could cause problems since if one manifest was fast and one was tree, we'd have to fall all the way back to flat manifests to compare them. This patch adds the ability to build a treemanifest from a fastmanifest for inmemory manifests that were copied from a commit that has both a fastmanifest and a treemanifest. We do it by diff'ing the inmemory fastmanifest with the commit fastmanifest, then applying that diff to the commit's treemanifest. Then we can compare that tree with the other tree. This is particularly useful when doing things like 'hg up master' after a pull. The new master commit probably has a treemanifest, but doesn't yet have a fastmanifest, while the commit the user is on probably has both. Now we can do that hg up without having to parse a full manifest. Once treemanifest has been enabled, every commit (both pulled and user created) should have treemanifests. Therefore this case should never happen when comparing two normal commits. So in theory, the only way to hit this case is when Mercurial does a manifest.copy() on a manifest that has a fastmanifest (like when reading a workingctx which must copy the commit manifest and apply working copy changes), since the copy will choose to copy the fastmanifest and leave the treemanifest behind. This patch addresses that case, so I think there shouldn't be other cases. Test Plan: Adds a test that covers this case. Reviewers: #mercurial, rmcelroy Reviewed By: rmcelroy Subscribers: rmcelroy, mjpieters Differential Revision: https://phabricator.intern.facebook.com/D4402604 Signature: t1:4402604:1484216866:1c075f314026aaf608095b4aca37c9a4277ababa
2017-01-12 23:26:21 +03:00
data = self._revlog.revision(self._node)
$ hg diff -r tip -r 1 --stat
c | 1 -
d | 1 -
2 files changed, 0 insertions(+), 2 deletions(-)
$ hg diff -r 1 -r tip --stat
c | 1 +
d | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)