sapling/tests/test-pushrebase-fastmanifest.t
Jun Wu 8997f2f15d windows: switch to the new Python runtime
Summary:
Switch to the new Python runtime. Remove parts that are incompatible and no
longer necessary, including:

- Building curses, python-lz4, and urllib3 (in build_nupkg.py).
- Mangling sys.path (in hgpython and entrypoint.py).
- Zip-related logic (in hgpython).
- Cargo features controlling build environment (in hgpython and hgmain).
- Zipping Python stdlib (in setup.py).
- Shipping files in `templates`, `help`, and most `contrib` files (in
  setup.py).

For the hgpython part, the new expectation is: in all cases (windows, linux,
make local, installed, buck), `edenscm.mercurial.entrypoint` and
`edenscmnative` modules are always directly importable and are always the
expected modules if imported. So the `hg` logic just imports and runs it
without having any `sys.path` related logic.

To explain it further:
- When installed on a POSIX system, the default `sys.path` contains
  site-packages.  Both edenscm and edenscmnative are in site-packages.
- When installed on Windows, the executable (hg.real.exe), python27.dll,
  python27.zip, and edenscmnative/ are all in a same directory. Therefore the
  default sys.path (exe dir + python27.zip) would be sufficient.
- When using `make local`, and run via `scm/hg/hg`, the `PySys_SetArgv` API
  (called by `hgpython`) inserts the `scm/hg` directory as `sys.path[0]`,
  therefore edenscm and edenscmnative in `scm/hg` will be imported as expected.

Since we no longer hard code paths to search for modules, this should fix
issues on systems with a different sys.path, ex. debian and ubuntu uses
"dist-packages" instead of "site-packages".

Note: IPython is broken. It seems to be a combination of newer Python version,
newer compiler and 64 bit (see [1]). It looks like prompt_toolkit incorrectly
uses untyped ctypes APIs where it passes "int/long"s to places expecting a
HANDLE. The ctypes library uses 4-byte integers for plain "int/long"s where a
HANDLE is 8 byte on 64 bit Windows.  The new interpreter is stricter somehow
and will error out in this case (also explains why D15912516 is needed).

The fix to prompt_toolkit was sent as
https://github.com/prompt-toolkit/python-prompt-toolkit/pull/930.

[1]: https://github.com/prompt-toolkit/python-prompt-toolkit/issues/406

Reviewed By: ikostia

Differential Revision: D15894694

fbshipit-source-id: 560d11ae28c1e65d58b760eac93701e753bd397e
2019-06-24 08:34:23 -07:00

78 lines
1.6 KiB
Perl

$ setconfig extensions.treemanifest=!
$ . helpers-usechg.sh
Setup
$ cat >> $HGRCPATH << EOF
> [ui]
> ssh = python "$RUNTESTDIR/dummyssh"
> EOF
Set up server repository
$ hg init server
$ cd server
$ cat >> .hg/hgrc << EOF
> [extensions]
> pushrebase=
> EOF
$ echo foo > a
$ echo foo > b
$ hg commit -Am 'initial'
adding a
adding b
$ hg book master
$ cd ..
Set up client repository 1 with pushrebase enabled
$ hg clone -q ssh://user@dummy/server client1
$ cd client1
$ cat >> .hg/hgrc << EOF
> [extensions]
> pushrebase=
> EOF
$ cd ..
Set up client repository 2 with pushrebase enabled / fastmanifest enabled
$ hg clone -q ssh://user@dummy/server client2
$ cd client2
$ cat >> .hg/hgrc << EOF
> [extensions]
> pushrebase=
> fastmanifest=
> EOF
$ cd ..
Create the dummy commit on client 1
$ cd client1
$ hg book mybook
$ echo "text" >> newfile
$ hg add newfile
$ hg commit -m 'dummy commit'
Test that pushing to a remotename gets rebased (client1 -> client2) works
$ hg push --to mybook ssh://user@dummy/client2
pushing to ssh://user@dummy/client2
searching for changes
remote: pushing 1 changeset:
remote: eb7a4df38d10 dummy commit
$ cd ../client2
$ hg log -G
o changeset: 1:eb7a4df38d10
| tag: tip
| user: test
| date: Thu Jan 01 00:00:00 1970 +0000
| summary: dummy commit
|
@ changeset: 0:2bb9d20e471c
bookmark: master
user: test
date: Thu Jan 01 00:00:00 1970 +0000
summary: initial