view tests/test-bundle-vs-outgoing.t @ 51871:cfd30df0f8e4

bundlerepo: fix mismatches with repository and revlog classes Both pytype and PyCharm complained that `write()` and `_write()` in the bundlephasecache class aren't proper overrides- indeed they seem to be missing an argument that the base class has. PyCharm and pytype also complained that the `revlog.revlog` class doesn't have a `_chunk()` method. That looks like it was moved from revlog to `_InnerRevlog` back in e8ad6d8de8b8, and wasn't caught because this module wasn't type checked. However, I couldn't figure out a syntax with `revlog.revlog._inner._chunk(self, rev)`, as it complained about passing too many args. `bundlerevlog._rawtext()` uses this `super(...)` style to call the super class, so hopefully that works, even with the wonky dynamic subclassing. The revlog class needed the `_InnerRevlog` field typed because it isn't set in the constructor. Finally, the vfs type hints look broken. This initially failed with: File "/mnt/c/Users/Matt/hg/mercurial/bundlerepo.py", line 65, in __init__: Function readonlyvfs.__init__ was called with the wrong arguments [wrong-arg-types] Expected: (self, vfs: mercurial.vfs.vfs) Actually passed: (self, vfs: Callable) Called from (traceback): line 232, in dirlog line 214, in __init__ I don't see a raw Callable, but I tried changing some of the vfs args to be typed as `vfsmod.abstractvfs`, but that class doesn't have `options`, so it failed elsewhere. `readonlyvfs` isn't a subclass of `vfs` (it's a subclass of `abstractvfs`), so I'm not sure how to handle that. It would be a shame to have to make a union of vfs subclasses (but not all of them have `options` either).
author Matt Harbison <matt_harbison@yahoo.com>
date Sat, 03 Aug 2024 01:33:13 -0400
parents eb586ed5d8ce
children
line wrap: on
line source

this structure seems to tickle a bug in bundle's search for
changesets, so first we have to recreate it

o  8
|
| o  7
| |
| o  6
|/|
o |  5
| |
o |  4
| |
| o  3
| |
| o  2
|/
o  1
|
o  0

  $ mkrev()
  > {
  >     revno=$1
  >     echo "rev $revno"
  >     echo "rev $revno" > foo.txt
  >     hg -q ci -m"rev $revno"
  > }

setup test repo1

  $ hg init repo1
  $ cd repo1
  $ echo "rev 0" > foo.txt
  $ hg ci -Am"rev 0"
  adding foo.txt
  $ mkrev 1
  rev 1

first branch

  $ mkrev 2
  rev 2
  $ mkrev 3
  rev 3

back to rev 1 to create second branch

  $ hg up -r1
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ mkrev 4
  rev 4
  $ mkrev 5
  rev 5

merge first branch to second branch

  $ hg up -C -r5
  0 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ HGMERGE=internal:local hg merge
  0 files updated, 1 files merged, 0 files removed, 0 files unresolved
  (branch merge, don't forget to commit)
  $ echo "merge rev 5, rev 3" > foo.txt
  $ hg ci -m"merge first branch to second branch"

one more commit following the merge

  $ mkrev 7
  rev 7

back to "second branch" to make another head

  $ hg up -r5
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ mkrev 8
  rev 8

the story so far

  $ hg log -G --template "{rev}\n"
  @  8
  |
  | o  7
  | |
  | o  6
  |/|
  o |  5
  | |
  o |  4
  | |
  | o  3
  | |
  | o  2
  |/
  o  1
  |
  o  0
  

check that "hg outgoing" really does the right thing

sanity check of outgoing: expect revs 4 5 6 7 8

  $ hg clone -r3 . ../repo2
  adding changesets
  adding manifests
  adding file changes
  added 4 changesets with 4 changes to 1 files
  new changesets 6ae4cca4e39a:478f191e53f8
  updating to branch default
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved

this should (and does) report 5 outgoing revisions: 4 5 6 7 8

  $ hg outgoing --template "{rev}\n" ../repo2
  comparing with ../repo2
  searching for changes
  4
  5
  6
  7
  8

test bundle (destination repo): expect 5 revisions

this should bundle the same 5 revisions that outgoing reported, but it

actually bundles 7

  $ hg bundle foo.bundle ../repo2
  searching for changes
  5 changesets found

test bundle (base revision): expect 5 revisions

this should (and does) give exactly the same result as bundle

with a destination repo... i.e. it's wrong too

  $ hg bundle --base 3 foo.bundle
  5 changesets found

  $ cd ..