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"
|
|
|
|
|
|
|
|
|
|
|
|
$ 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]
|
2018-01-09 23:59:00 +03:00
|
|
|
> 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
|
2018-01-09 23:59:00 +03:00
|
|
|
> treemanifest=
|
2017-04-20 07:14:03 +03:00
|
|
|
>
|
|
|
|
> [remotefilelog]
|
|
|
|
> usefastdatapack=True
|
|
|
|
> reponame=master
|
|
|
|
>
|
|
|
|
> [fastmanifest]
|
|
|
|
> usetree=True
|
|
|
|
> usecache=True
|
|
|
|
>
|
|
|
|
> [treemanifest]
|
|
|
|
> autocreatetrees=True
|
2017-04-20 07:14:03 +03:00
|
|
|
> 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
|
2017-01-13 03:13:43 +03:00
|
|
|
File "*fastmanifest/implementation.py", line *, in loadflat (glob)
|
2018-03-12 21:10:15 +03:00
|
|
|
data = self.revlog.revision(self._node)
|
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
|
|
|
|
|
|
|
|
|
|
|
# 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
|
2017-01-13 03:13:43 +03:00
|
|
|
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
|
2017-01-13 03:13:43 +03:00
|
|
|
File "*fastmanifest/implementation.py", line *, in loadflat (glob)
|
2018-03-12 21:10:15 +03:00
|
|
|
data = self.revlog.revision(self._node)
|
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
|
|
|
|
|
|
|
$ 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(-)
|