Mercurial > hg
view tests/test-merge-commit.t @ 40393:229d23cdb203
exchangev2: support fetching shallow files history
This commit teaches the exchangev2 client code to handle fetching shallow
files data.
Only shallow fetching of files data is supported: shallow fetching of
changeset and manifest data is explicitly not yet supported.
Previously, we would fetch file revisions for changesets that were received
by the current pull operation. In the new model, we calculate the set of
"relevant" changesets given the pull depth and only fetch files data for
those changesets.
We also teach the "filesdata" command invocation to vary parameters as needed.
The implementation here is far from complete or optimal. Subsequent pulls will
end up re-fetching a lot of files data. But the application of this data should
mostly be a no-op on the client, so it isn't a big deal.
Depending on the order file revisions are fetched in, revisions could get
inserted with the wrong revision number relationships. I think the best way
to deal with this is to remove revision numbers from storage and to either
dynamically derive them (by reconstructing a DAG from nodes/parents) or remove
revision numbers from the file storage interface completely.
A missing API that we'll likely want to write pretty soon is "ensure files
for revision(s) are present." We can kind of cajole exchangev2.pull() to do
this. But it isn't very efficient. For example, in simple cases like
widening the store to obtain data for a single revision, it is probably
more efficient to walk the manifest and find exactly which file revisions
are missing and to make explicit requests for just their data. In more
advanced cases, asking the server for all files data may be more efficient,
even though it requires sending data the client already has. There is tons
of room for future experimentation here. And TBH I'm not sure what the
final state will be.
Anyway, this commit gets us pretty close to being able to have shallow
and narrow checkouts with exchangev2/sqlite storage. Close enough that a
minimal extension should be able to provide fill in the gaps until the code
in core stabilizes and there is a user-facing way to trigger the
narrow/shallow bits from `hg clone` without also implying using of the
narrow extension...
Differential Revision: https://phab.mercurial-scm.org/D5169
author | Gregory Szorc <gregory.szorc@gmail.com> |
---|---|
date | Fri, 19 Oct 2018 12:30:49 +0200 |
parents | d4e62df1c73d |
children | 91a0bc50b288 |
line wrap: on
line source
Check that renames are correctly saved by a commit after a merge Test with the merge on 3 having the rename on the local parent $ hg init a $ cd a $ echo line1 > foo $ hg add foo $ hg ci -m '0: add foo' $ echo line2 >> foo $ hg ci -m '1: change foo' $ hg up -C 0 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg mv foo bar $ rm bar $ echo line0 > bar $ echo line1 >> bar $ hg ci -m '2: mv foo bar; change bar' created new head $ hg merge 1 merging bar and foo to bar 0 files updated, 1 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit) $ cat bar line0 line1 line2 $ hg ci -m '3: merge with local rename' $ hg debugindex bar rev linkrev nodeid p1 p2 0 2 d35118874825 000000000000 000000000000 1 3 5345f5ab8abd 000000000000 d35118874825 $ hg debugrename bar bar renamed from foo:9e25c27b87571a1edee5ae4dddee5687746cc8e2 $ hg debugindex foo rev linkrev nodeid p1 p2 0 0 690b295714ae 000000000000 000000000000 1 1 9e25c27b8757 690b295714ae 000000000000 Revert the content change from rev 2: $ hg up -C 2 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ rm bar $ echo line1 > bar $ hg ci -m '4: revert content change from rev 2' created new head $ hg log --template '{rev}:{node|short} {parents}\n' 4:2263c1be0967 2:0f2ff26688b9 3:0555950ead28 2:0f2ff26688b9 1:5cd961e4045d 2:0f2ff26688b9 0:2665aaee66e9 1:5cd961e4045d 0:2665aaee66e9 This should use bar@rev2 as the ancestor: $ hg --debug merge 3 searching for copies back to rev 1 resolving manifests branchmerge: True, force: False, partial: False ancestor: 0f2ff26688b9, local: 2263c1be0967+, remote: 0555950ead28 preserving bar for resolve of bar starting 4 threads for background file closing (?) bar: versions differ -> m (premerge) picked tool ':merge' for bar (binary False symlink False changedelete False) merging bar my bar@2263c1be0967+ other bar@0555950ead28 ancestor bar@0f2ff26688b9 premerge successful 0 files updated, 1 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit) $ cat bar line1 line2 $ hg ci -m '5: merge' $ hg debugindex bar rev linkrev nodeid p1 p2 0 2 d35118874825 000000000000 000000000000 1 3 5345f5ab8abd 000000000000 d35118874825 2 4 ff4b45017382 d35118874825 000000000000 3 5 3701b4893544 ff4b45017382 5345f5ab8abd Same thing, but with the merge on 3 having the rename on the remote parent: $ cd .. $ hg clone -U -r 1 -r 2 a b adding changesets adding manifests adding file changes added 3 changesets with 3 changes to 2 files (+1 heads) new changesets 2665aaee66e9:0f2ff26688b9 $ cd b $ hg up -C 1 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg merge 2 merging foo and bar to bar 0 files updated, 1 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit) $ cat bar line0 line1 line2 $ hg ci -m '3: merge with remote rename' $ hg debugindex bar rev linkrev nodeid p1 p2 0 2 d35118874825 000000000000 000000000000 1 3 5345f5ab8abd 000000000000 d35118874825 $ hg debugrename bar bar renamed from foo:9e25c27b87571a1edee5ae4dddee5687746cc8e2 $ hg debugindex foo rev linkrev nodeid p1 p2 0 0 690b295714ae 000000000000 000000000000 1 1 9e25c27b8757 690b295714ae 000000000000 Revert the content change from rev 2: $ hg up -C 2 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ rm bar $ echo line1 > bar $ hg ci -m '4: revert content change from rev 2' created new head $ hg log --template '{rev}:{node|short} {parents}\n' 4:2263c1be0967 2:0f2ff26688b9 3:3ffa6b9e35f0 1:5cd961e4045d 2:0f2ff26688b9 2:0f2ff26688b9 0:2665aaee66e9 1:5cd961e4045d 0:2665aaee66e9 This should use bar@rev2 as the ancestor: $ hg --debug merge 3 searching for copies back to rev 1 resolving manifests branchmerge: True, force: False, partial: False ancestor: 0f2ff26688b9, local: 2263c1be0967+, remote: 3ffa6b9e35f0 preserving bar for resolve of bar starting 4 threads for background file closing (?) bar: versions differ -> m (premerge) picked tool ':merge' for bar (binary False symlink False changedelete False) merging bar my bar@2263c1be0967+ other bar@3ffa6b9e35f0 ancestor bar@0f2ff26688b9 premerge successful 0 files updated, 1 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit) $ cat bar line1 line2 $ hg ci -m '5: merge' $ hg debugindex bar rev linkrev nodeid p1 p2 0 2 d35118874825 000000000000 000000000000 1 3 5345f5ab8abd 000000000000 d35118874825 2 4 ff4b45017382 d35118874825 000000000000 3 5 3701b4893544 ff4b45017382 5345f5ab8abd $ cd ..