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:
Our `rename` is not atomic:
```
def rename(src, dst):
"""Rename file src to dst, replacing dst if it exists"""
try:
os.rename(src, dst)
except OSError as e:
if e.errno != errno.EEXIST:
raise
unlink(dst)
# What if the process is interrupted here?
os.rename(src, dst)
```
However, the `MoveFileEx` Windows API provides a way to to
replace the existing file, thus eliminating the need to do `unlink`.
Unfortunately, it only works for files, not for dirs, therefore
we're introducing a new file-specific rename function.
Differential Revision: D12940555
fbshipit-source-id: a6749a9b16a285788de0f5c06d51a15c919166ce
