view tests/test-narrow-pull.t @ 39872:733db72f0f54

revlog: move revision verification out of verify File revision verification is performing low-level checks of file storage, namely that flags are appropriate and revision data can be resolved. Since these checks are somewhat revlog-specific and may not be appropriate for alternate storage backends, this commit moves those checks from verify.py to revlog.py. Because we're now emitting warnings/errors that apply to specific revisions, we taught the iverifyproblem interface to expose the problematic node and to report this node in verify output. This was necessary to prevent unwanted test changes. After this change, revlog.verifyintegrity() and file verify code in verify.py both iterate over revisions and resolve their fulltext. But they do so in separate loops. (verify.py needs to resolve fulltexts as part of calling renamed() - at least when using revlogs.) This should add overhead. But on the mozilla-unified repo: $ hg verify before: time: real 700.640 secs (user 585.520+0.000 sys 23.480+0.000) after: time: real 682.380 secs (user 570.370+0.000 sys 22.240+0.000) I'm not sure what's going on. Maybe avoiding the filelog attribute proxies shaved off enough time to offset the losses? Maybe fulltext resolution has less overhead than I thought? I've left a comment indicating the potential for optimization. But because it doesn't produce a performance regression on a large repository, I'm not going to worry about it. Differential Revision: https://phab.mercurial-scm.org/D4745
author Gregory Szorc <gregory.szorc@gmail.com>
date Mon, 24 Sep 2018 11:27:47 -0700
parents f1186c292d03
children 7db1619af061
line wrap: on
line source

  $ . "$TESTDIR/narrow-library.sh"

  $ hg init master
  $ cd master
  $ cat >> .hg/hgrc <<EOF
  > [narrow]
  > serveellipses=True
  > EOF
  $ for x in `$TESTDIR/seq.py 10`
  > do
  >   echo $x > "f$x"
  >   hg add "f$x"
  >   hg commit -m "Commit f$x"
  > done
  $ cd ..

narrow clone a couple files, f2 and f8

  $ hg clone --narrow ssh://user@dummy/master narrow --include "f2" --include "f8"
  requesting all changes
  adding changesets
  adding manifests
  adding file changes
  added 5 changesets with 2 changes to 2 files
  new changesets *:* (glob)
  updating to branch default
  2 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ cd narrow
  $ ls
  f2
  f8
  $ cat f2 f8
  2
  8

  $ cd ..

change every upstream file twice

  $ cd master
  $ for x in `$TESTDIR/seq.py 10`
  > do
  >   echo "update#1 $x" >> "f$x"
  >   hg commit -m "Update#1 to f$x" "f$x"
  > done
  $ for x in `$TESTDIR/seq.py 10`
  > do
  >   echo "update#2 $x" >> "f$x"
  >   hg commit -m "Update#2 to f$x" "f$x"
  > done
  $ cd ..

look for incoming changes

  $ cd narrow
  $ hg incoming --limit 3
  comparing with ssh://user@dummy/master
  searching for changes
  changeset:   5:ddc055582556
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     Update#1 to f1
  
  changeset:   6:f66eb5ad621d
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     Update#1 to f2
  
  changeset:   7:c42ecff04e99
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     Update#1 to f3
  

Interrupting the pull is safe
  $ hg --config hooks.pretxnchangegroup.bad=false pull -q
  transaction abort!
  rollback completed
  abort: pretxnchangegroup.bad hook exited with status 1
  [255]
  $ hg id
  223311e70a6f tip

pull new changes down to the narrow clone. Should get 8 new changesets: 4
relevant to the narrow spec, and 4 ellipsis nodes gluing them all together.

  $ hg pull
  pulling from ssh://user@dummy/master
  searching for changes
  adding changesets
  adding manifests
  adding file changes
  added 9 changesets with 4 changes to 2 files
  new changesets *:* (glob)
  (run 'hg update' to get a working copy)
  $ hg log -T '{rev}: {desc}\n'
  13: Update#2 to f10
  12: Update#2 to f8
  11: Update#2 to f7
  10: Update#2 to f2
  9: Update#2 to f1
  8: Update#1 to f8
  7: Update#1 to f7
  6: Update#1 to f2
  5: Update#1 to f1
  4: Commit f10
  3: Commit f8
  2: Commit f7
  1: Commit f2
  0: Commit f1
  $ hg update tip
  2 files updated, 0 files merged, 0 files removed, 0 files unresolved

add a change and push it

  $ echo "update#3 2" >> f2
  $ hg commit -m "Update#3 to f2" f2
  $ hg log f2 -T '{rev}: {desc}\n'
  14: Update#3 to f2
  10: Update#2 to f2
  6: Update#1 to f2
  1: Commit f2
  $ hg push
  pushing to ssh://user@dummy/master
  searching for changes
  remote: adding changesets
  remote: adding manifests
  remote: adding file changes
  remote: added 1 changesets with 1 changes to 1 files
  $ cd ..

  $ cd master
  $ hg log f2 -T '{rev}: {desc}\n'
  30: Update#3 to f2
  21: Update#2 to f2
  11: Update#1 to f2
  1: Commit f2
  $ hg log -l 3 -T '{rev}: {desc}\n'
  30: Update#3 to f2
  29: Update#2 to f10
  28: Update#2 to f9

Can pull into repo with a single commit

  $ cd ..
  $ hg clone -q --narrow ssh://user@dummy/master narrow2 --include "f1" -r 0
  $ cd narrow2
  $ hg pull -q -r 1
  transaction abort!
  rollback completed
  abort: pull failed on remote
  [255]

Can use 'hg share':
  $ cat >> $HGRCPATH <<EOF
  > [extensions]
  > share=
  > EOF

  $ cd ..
  $ hg share narrow2 narrow2-share
  updating working directory
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ cd narrow2-share
  $ hg status

We should also be able to unshare without breaking everything:
  $ hg unshare
  $ hg verify
  checking changesets
  checking manifests
  crosschecking files in changesets and manifests
  checking files
  checked 1 changesets with 1 changes to 1 files