Summary:
We've seen several cases where the number of packfiles explodes and causes
Mercurial to slowly becoming unusable due to spending most of its time scanning
the filesytem for new packfiles. In the case of tree, Mercurial will blow aways
the hgcache/manifest directory entirely, causing concurrent Mercurial processes
to fail to commit packfiles to disk.
Let's just count the number of commits we've had so far, and trigger a repack
when it goes over a threshold.
Reviewed By: quark-zju
Differential Revision: D17677222
fbshipit-source-id: 99c31c6137d792be1f6de3c298ebff8a4372926e
Summary:
For Eden we currently have a gap in our post-mount behavior;
we don't perform the update hooks for a freshly cloned and mounted repo.
The thought is that we'll explicitly trigger them by invoking `hg
debugedenrunpostupdatehook` at the end of the mount sequence.
Reviewed By: quark-zju
Differential Revision: D17237197
fbshipit-source-id: 9c2212c61735068c287eb98761503ce31bfee8a6
Summary:
It does not seem to get used anywhere. Its usage of `scmutil.revrange` can
potentailly trigger a false positive "legacy revision number used" warning.
Reviewed By: chadaustin
Differential Revision: D16910635
fbshipit-source-id: 0b84d4b6a85678c581ccf1754bfbefbc97d8c055
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: `hg debugedenimporthelper --get-file-size PATH:REV` will print the size of the given file
Reviewed By: chadaustin, xavierd
Differential Revision: D16009279
fbshipit-source-id: 6edb01dd154a467cdd26c0ced1d4ae82411088f1
Summary:
This allows `commands/__init__.py` and `commands/<command>.py` to both import
the module. So there is no need for `__init__.py` to manually update the
command table.
Reviewed By: kulshrax
Differential Revision: D15640719
fbshipit-source-id: 684983cf91006ec0d504cb01a5f616c0d1f7ac29
Summary: This diff improves `hg debugedenimporthelper` reliability by retrying when a possible race condition happens in Mercurial. This could save us from the cost of restarting the importer.
Reviewed By: simpkins
Differential Revision: D15150902
fbshipit-source-id: 67af2e044e9c3a16c073a0d1252fbfc2e5ce1014
Summary: We are seeing some errors are being thrown as `RepoResetError` but it is quite difficult to tell what exactly is the error from our current logging. This diff improves the logging to help us debug the problem.
Reviewed By: chadaustin, simpkins
Differential Revision: D15067819
fbshipit-source-id: fefb27497076e42736a09bb3be3a0734fd67668d
Summary:
Closing a repo is required to commit the pending transactions, or to run a
background repack when packfiles were downloaded. Usually, the close method is
called in dispatch after a command is run and a valid repository was passed via
-R. The debugedenimporthelper however may open the repository manually, and
since it doesn't close it, we may end up with a large number of packfiles.
Let's manually close it to avoid this issue.
Reviewed By: simpkins
Differential Revision: D14531514
fbshipit-source-id: 9b2d1648775e4a2c9eea4c232bf0ae4fee43297d
Summary:
When using the `debugedenimporthelper` subcommand that is part of `hg` itself
it is much more important to make sure that we don't try to use `stdout` as
the import communication mechanism.
The old `hg_import_helper.py` script more carefully set up its own `UI` object
to try and avoid ever printing any messages to `stdout`. However it isn't
easily possible to do this as part of the normal `hg` program. Therefore
abort the command if `hg debugedenimporthelper` is ever run without an
`--out-fd` argument.
This also helps avoid potentially confusing users by printing binary data to
stdout if they invoke accidentally `hg debugedenimporthelper` interactively in
a terminal.
Reviewed By: chadaustin
Differential Revision: D14222372
fbshipit-source-id: 7e0829dff41b2bca28c7f4539b90c6c354f8c79f
Summary:
This starts to fix some of the `hg debugedenimporthelper` behavior and make it
work more like most other hg subcommands with respect to how it finds the hg
repository.
Previously the code was copied into hg largely as-is from an external script
that took the repository path as a separate argument. This resulted in
confusing behavior as it completely ignored the normal repository object
opened by `hg`.
This makes `debugedenimporthelper` honor the normal hg repo object if the
extra repository path argument is not specified.
Reviewed By: chadaustin
Differential Revision: D14222323
fbshipit-source-id: 57048178b588dd1dd7150184665d6c13427d6b56
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
