Mercurial > hg
view tests/test-push-checkheads-partial-C2.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 | 5996640fc6fe |
children |
line wrap: on
line source
==================================== Testing head checking code: Case C-2 ==================================== Mercurial checks for the introduction of new heads on push. Evolution comes into play to detect if existing branches on the server are being replaced by some of the new one we push. This case is part of a series of tests checking this behavior. Category C: case were the branch is only partially obsoleted TestCase 2: 2 changeset branch, only the base is rewritten .. old-state: .. .. * 2 changeset branch .. .. new-state: .. .. * 1 new changesets branches superseding only the base of the old one .. * The old branch is still alive (base is obsolete, head is alive) .. .. expected-result: .. .. * push denied .. .. graph-summary: .. .. B ○ .. | .. A ø⇠◔ A' .. |/ .. ● $ . $TESTDIR/testlib/push-checkheads-util.sh Test setup ---------- $ mkdir C2 $ cd C2 $ setuprepos creating basic server and client repo updating to branch default 2 files updated, 0 files merged, 0 files removed, 0 files unresolved $ cd server $ mkcommit B0 $ cd ../client $ hg pull pulling from $TESTTMP/C2/server searching for changes adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files new changesets d73caddc5533 (1 drafts) (run 'hg update' to get a working copy) $ hg up 0 0 files updated, 0 files merged, 1 files removed, 0 files unresolved $ mkcommit A1 created new head $ hg debugobsolete `getid "desc(A0)" ` `getid "desc(A1)"` 1 new obsolescence markers obsoleted 1 changesets 1 new orphan changesets $ hg log -G --hidden @ f6082bc4ffef (draft): A1 | | * d73caddc5533 (draft): B0 | | | x 8aaa48160adc (draft): A0 |/ o 1e4be0697311 (public): root Actual testing -------------- $ hg push --rev 'desc(A1)' pushing to $TESTTMP/C2/server searching for changes abort: push creates new remote head f6082bc4ffef (merge or see 'hg help push' for details about pushing new heads) [20] $ cd ../..