view tests/test-addremove.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 824b687ff6af
children
line wrap: on
line source

  $ hg init rep
  $ cd rep
  $ mkdir dir
  $ touch foo dir/bar
  $ hg -v addremove
  adding dir/bar
  adding foo
  $ hg -v commit -m "add 1"
  committing files:
  dir/bar
  foo
  committing manifest
  committing changelog
  committed changeset 0:6f7f953567a2
  $ cd dir/
  $ touch ../foo_2 bar_2
  $ hg -v addremove
  adding dir/bar_2
  adding foo_2
  $ hg -v commit -m "add 2"
  committing files:
  dir/bar_2
  foo_2
  committing manifest
  committing changelog
  committed changeset 1:e65414bf35c5
  $ cd ..
  $ hg forget foo
  $ hg -v addremove
  adding foo
  $ hg forget foo

  $ hg -v addremove nonexistent
  nonexistent: $ENOENT$
  [1]

  $ cd ..

  $ hg init subdir
  $ cd subdir
  $ mkdir dir
  $ cd dir
  $ touch a.py
  $ hg addremove 'glob:*.py'
  adding a.py
  $ hg forget a.py
  $ hg addremove -I 'glob:*.py'
  adding a.py
  $ hg forget a.py
  $ hg addremove
  adding dir/a.py
  $ cd ..

  $ hg init sim
  $ cd sim
  $ echo a > a
  $ echo a >> a
  $ echo a >> a
  $ echo c > c
  $ hg commit -Ama
  adding a
  adding c
  $ mv a b
  $ rm c
  $ echo d > d
  $ hg addremove -n -s 50 # issue 1696
  removing a
  adding b
  removing c
  adding d
  recording removal of a as rename to b (100% similar)
  $ hg addremove -ns 50 --color debug
  [ui.addremove.removed ui.status|removing a]
  [ui.addremove.added ui.status|adding b]
  [ui.addremove.removed ui.status|removing c]
  [ui.addremove.added ui.status|adding d]
  [ ui.status|recording removal of a as rename to b (100% similar)]
  $ hg addremove -s 50
  removing a
  adding b
  removing c
  adding d
  recording removal of a as rename to b (100% similar)
  $ hg commit -mb
  $ cp b c
  $ hg forget b
  $ hg addremove -s 50
  adding b
  adding c

  $ rm c

  $ hg ci -A -m "c" nonexistent
  nonexistent: $ENOENT$
  abort: failed to mark all new/missing files as added/removed
  [255]

  $ hg st
  ! c
  $ cd ..