Summary:
`util.fdopen` now adds workarounds for read+write+seek files on Windows.
This should solve issues we have seen on Windows behaviors.
See https://www.mercurial-scm.org/repo/hg/rev/3686fa2b8eee for the Windows weirdness.
Here is a minimal program to reproduce the weirdness:
```
import os
f = open("a.txt", "wb+")
# Write 12 bytes
f.write(b"b" * 12)
# Read byte slice 2..5
f.seek(2, os.SEEK_SET)
data = f.read(3)
# Try SEEK_END
f.seek(0, os.SEEK_END)
print("%d (expect 12)" % f.tell()) # got 5 using some python.exe
```
Reviewed By: xavierd
Differential Revision: D16033678
fbshipit-source-id: 4f17c463d9bfcc0cdd38d1b15f2a9e38e5b4c132
Summary:
D13853115 adds `edenscm/` to `sys.path` and code still uses `import mercurial`.
That has nasty problems if both `import mercurial` and
`import edenscm.mercurial` are used, because Python would think `mercurial.foo`
and `edenscm.mercurial.foo` are different modules so code like
`try: ... except mercurial.error.Foo: ...`, or `isinstance(x, mercurial.foo.Bar)`
would fail to handle the `edenscm.mercurial` version. There are also some
module-level states (ex. `extensions._extensions`) that would cause trouble if
they have multiple versions in a single process.
Change imports to use the `edenscm` so ideally the `mercurial` is no longer
imported at all. Add checks in extensions.py to catch unexpected extensions
importing modules from the old (wrong) locations when running tests.
Reviewed By: phillco
Differential Revision: D13868981
fbshipit-source-id: f4e2513766957fd81d85407994f7521a08e4de48
Summary:
Move top-level Python packages `mercurial`, `hgext` and `hgdemandimport` to
a new top-level package `edenscm`. This allows the Python packages provided by
the upstream Mercurial to be installed side-by-side.
To maintain compatibility, `edenscm/` gets added to `sys.path` in
`mercurial/__init__.py`.
Reviewed By: phillco, ikostia
Differential Revision: D13853115
fbshipit-source-id: b296b0673dc54c61ef6a591ebc687057ff53b22e
