view tests/test-flags.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 d0abd7949ea3
children ccd76e292be5
line wrap: on
line source

#require execbit

  $ umask 027

  $ hg init test1
  $ cd test1
  $ touch a b
  $ hg add a b
  $ hg ci -m "added a b"

  $ cd ..
  $ hg clone test1 test3
  updating to branch default
  2 files updated, 0 files merged, 0 files removed, 0 files unresolved

  $ hg init test2
  $ cd test2
  $ hg pull ../test1
  pulling from ../test1
  requesting all changes
  adding changesets
  adding manifests
  adding file changes
  added 1 changesets with 2 changes to 2 files
  new changesets 22a449e20da5
  (run 'hg update' to get a working copy)
  $ hg co
  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ chmod +x a
  $ hg ci -m "chmod +x a"

the changelog should mention file a:

  $ hg tip --template '{files}\n'
  a

  $ cd ../test1
  $ echo 123 >>a
  $ hg ci -m "a updated"

  $ hg pull ../test2
  pulling from ../test2
  searching for changes
  adding changesets
  adding manifests
  adding file changes
  added 1 changesets with 0 changes to 0 files (+1 heads)
  new changesets 7f4313b42a34
  1 local changesets published
  (run 'hg heads' to see heads, 'hg merge' to merge)
  $ hg heads
  changeset:   2:7f4313b42a34
  tag:         tip
  parent:      0:22a449e20da5
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     chmod +x a
  
  changeset:   1:c6ecefc45368
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     a updated
  
  $ hg history
  changeset:   2:7f4313b42a34
  tag:         tip
  parent:      0:22a449e20da5
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     chmod +x a
  
  changeset:   1:c6ecefc45368
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     a updated
  
  changeset:   0:22a449e20da5
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     added a b
  

  $ hg -v merge
  resolving manifests
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  (branch merge, don't forget to commit)
  $ cat a
  123
  $ [ -x a ]

  $ cd ../test3
  $ echo 123 >>b
  $ hg ci -m "b updated"

  $ hg pull ../test2
  pulling from ../test2
  searching for changes
  adding changesets
  adding manifests
  adding file changes
  added 1 changesets with 0 changes to 0 files (+1 heads)
  new changesets 7f4313b42a34
  (run 'hg heads' to see heads, 'hg merge' to merge)
  $ hg heads
  changeset:   2:7f4313b42a34
  tag:         tip
  parent:      0:22a449e20da5
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     chmod +x a
  
  changeset:   1:dc57ead75f79
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     b updated
  
  $ hg history
  changeset:   2:7f4313b42a34
  tag:         tip
  parent:      0:22a449e20da5
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     chmod +x a
  
  changeset:   1:dc57ead75f79
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     b updated
  
  changeset:   0:22a449e20da5
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     added a b
  

  $ hg -v merge
  resolving manifests
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  (branch merge, don't forget to commit)

  $ ls -l ../test[123]/a > foo
  $ cut -b 1-10 < foo
  -rwxr-x---
  -rwxr-x---
  -rwxr-x---

  $ hg debugindex a
     rev linkrev nodeid       p1           p2
       0       0 b80de5d13875 000000000000 000000000000
  $ hg debugindex -R ../test2 a
     rev linkrev nodeid       p1           p2
       0       0 b80de5d13875 000000000000 000000000000
  $ hg debugindex -R ../test1 a
     rev linkrev nodeid       p1           p2
       0       0 b80de5d13875 000000000000 000000000000
       1       1 7fe919cc0336 b80de5d13875 000000000000

  $ cd ..