Summary: Per title, `hg debughttp` now prints out the hostname that the API server reports rather than the hostname in the URL we used to connect to it. The reason for this is that if the API server is behind a VIP, we get the actual hostname rather than just the VIP URL.
Differential Revision: D15170618
fbshipit-source-id: 9af5480f9987d8ea9c914baf3b62a00ad88d1b32
Summary:
I noticed this takes 500+ms in some cases. Let's track both the old
computation and the new, and flag them so we can differentiate between them.
Differential Revision: D15156559
fbshipit-source-id: ec2983081e4fa01d017212783e3fcb040f9fd4e5
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: `accessed(..)` method will allow to log the fact of a name access, that is needed to track interesting remotenames.
Reviewed By: markbt
Differential Revision: D15047919
fbshipit-source-id: 29566653e742b3f24b742ffce2282baed833ea61
Summary: We have turned off hgignroe globally for a while. Let's remove the code now.
Reviewed By: kulshrax
Differential Revision: D15110678
fbshipit-source-id: d0c2061413f6a48a6bfda5b26d15007e7890d20c
Summary:
This diff adds support for extension source code inlined into configuration.
The main intended use case is to use Chef to quickly deploy config changes.
The config change can be inlined extensions that patch broken logic.
Since extensions are more powerful than pure config changes, we gain the
ability to hotfix more complicated issues.
In theory, Chef can also write files to the filesystem. It's less convenient
because different OSes might require different paths, cleaning them up might
be extra work.
Reviewed By: ikostia
Differential Revision: D15073429
fbshipit-source-id: 7696bdce72bf7222debc72002173feb7de95198f
Summary:
To be able to investigate problems with dangling lock files "infinitepushbackup" and "prefetch".
- "infinitepushbackup", file "infinitepushbackup.lock" in repo.sharedvfs
- "prefetchlock", file "prefetchlock" in repo.svfs
Also some small fixes around.
- Crate "undolog" directory if it doesn't exist.
- `report` function was restructed. Now if lock checking method is not passed
lock will be checked with `lockmod.lock`.
Reviewed By: markbt
Differential Revision: D14949807
fbshipit-source-id: 02143ff923145e67e88c5627cf3355a834823b6d
Summary:
The error-chain crate is un-maintained and triggers warnings when compiling
with new versions of Rust. Let's use the failure crate instead to be consistent
with the other crates.
Reviewed By: singhsrb
Differential Revision: D15106306
fbshipit-source-id: 8edcf9f9aaf4b6e2d5f214b26fed3e72d4f3acd1
Summary:
D14185380 made it so pushrebase will always force pushkey to get a
transaction. This has the side effect of making infinitepush bundles take the
lock and fire transactions. They should do neither.
Let's instead request the transaction at bookmark edit time.
Reviewed By: singhsrb
Differential Revision: D15094917
fbshipit-source-id: 6573447a7ba61b1853a37eacb1b3e767abb3f27f
Summary:
When using ui.configoverrides, it was previously just backing up
self._rcfg. It turns out that calling ui.setconfig (which is called as part of
configoverrides) will mark the given config as pinned and potentially
unserializable. If a config is pinned, that means we will never again read a
value into it, so when we open a bundlerepo and attempt to load the repo
specific hgrc into it, any pinned values simply don't get written.
So there are two bugs here:
1. overriding a config should not result in the config key being considered
pinned forever.
2. Cloning a ui should reset the pinned list since we don't actually clone any
of the pinned data into the new ui
Either of these alone would fix our problem with bundlerepos, but both are
necessary for general correctness.
Reviewed By: ikostia
Differential Revision: D15074037
fbshipit-source-id: 37f67f13f1d2975299be97d796b52ec2b97bca24
Summary:
The `path` argument passed to the follow revset is absolute. So `path` instead
of `relpath` should be used.
Reviewed By: DurhamG
Differential Revision: D15071189
fbshipit-source-id: 6aec76fa1a8cabd545a375aa40448cc75dbd1d6d
Summary: Release the GIL during data fetching to allow for progress bars to update properly. The data fetching code is pure Rust and does not interact with the Python interpreter at all, so releasing the GIL here is safe.
Differential Revision: D15051852
fbshipit-source-id: 144da953720951f9a30aadfc2b7fc8c8bc6b14aa
Summary:
When detecting split completion for the purposes of recording mutation, we used
`cmdutil.comparechunks`. This doesn't work for curses-recordings where the
only change is that some lines of a patch were excluded.
A simpler check is to just generate the patch that split is going to use, and
see if that matches the original patch.
Additionally, prevent the insertion of empty split records, as this can
cause crashes.
Reviewed By: mitrandir77
Differential Revision: D15063983
fbshipit-source-id: ba717d7f065faea93a500caaf10a1dbf582c7ab1
Summary:
Rather than relying on implicit conversion from a missing visibleheads file,
explicitly convert visibility information from obsmarkers when enabling
visibility tracking.
Reviewed By: mitrandir77
Differential Revision: D15063290
fbshipit-source-id: 44309f3cdf92c4ae100570b3bd98a240999ed558
Summary: Track visibility changes in the blackbox log to help with debugging issues.
Reviewed By: mitrandir77
Differential Revision: D15062971
fbshipit-source-id: c547618168f5eb08e6343e0b0d97db136e151a7a
Summary:
Ordinarily loops are prevented in the mutation graph as the predecessors must exist
at the point that the successor is created. However, backfilling from a complex
obsolescence graph may inadvertently introduce cycles.
Since loops are invalid, we can safely ignore any mutation edges that may
introduce them. The `allpredecessors` and `allsuccessors` functions already
do this.
Add loop detection and ignoring to the `predecessorsset` and `successorssets`
functions.
Reviewed By: mitrandir77
Differential Revision: D15062399
fbshipit-source-id: fe892d9236c8d8dc4e1322b82618ab4bca35d30a
Summary:
Use the graphnode `-` for all invisible commits, even obsolete ones.
Users will only see them in their logs if:
- they run log with `--hidden`.
- they have invisible commits that are temporarily unhidden (e.g. they've checked it out).
Reviewed By: mitrandir77
Differential Revision: D15061894
fbshipit-source-id: 86873bd86cb15cef72dae248b8e2a636378cc547
Summary:
When computing the fate of a commit, if we find the immediate successor is the
next visible commit, we return the operation of the mutation record for that
single operation. If it's not available, we then look at whether or not the
commit is public to decide between the fallbacks of `land` or `rewrite`.
Unfortunately, not all land operations end up with a `land` op. In particular,
obsmarkers created with pullcreatemarkers and then backfilled into mutation
records have a blank operation, and so we show `rewrite` here when we should
show `land`.
Switch around how we calculate the fate. Compute a default operation of `rewrite`
or `land`, based on the phase of the successor, and then use that if the successor
is not the immediate successor, or if the recorded operation is blank.
Reviewed By: mitrandir77
Differential Revision: D15061863
fbshipit-source-id: 753b0b58f84e653b40f9918f7ad3b3adfff359d8
Summary:
In the automigrate step at the start of pull, perform automigrations for
mutation and visibility.
If `mutation.automigrate` is set to true, then backfill obsmarkers into the
mutation store. This step can take a couple of seconds for large obsstores, so
print a message.
If `visibility.automigrate` is set to `"start"`, switch to explicit visibility
tracking. If it is set to `"stop"`, switch back to obsmarker-based tracking.
Reviewed By: mitrandir77
Differential Revision: D15046139
fbshipit-source-id: 284268d42b52c6b296c5c1b73db7bc218ae29a0a
Summary:
Clean up some of the calls to `ui.log` and how they appear in blackbox logging.
* Make the names of the events consistently use `snake_case`.
* For watchman, only log once for each watchman command. Include whether or not it failed.
* Unify `fsmonitor` logging under the `fsmonitor` event.
* Omit the second argument when it is empty - it is optional and does nothing when empty.
* Increase the number of blackbox lines included in rage to 100.
Reviewed By: quark-zju
Differential Revision: D14949868
fbshipit-source-id: a9aa8251e71ae7ca556c08116f8f7c61ff472218
Summary: Add a new config option to toggle file validation.
Differential Revision: D15034687
fbshipit-source-id: 3783ea1dacad9d1e494a5de1388f703db0ed1129
Summary: We have to pass a lot of config options across the FFI boundary; these are currently passed as arguments to the Eden API client constructor. Let's use argument unpacking to avoid repeating a bunch of argument names in the call to the constructor.
Differential Revision: D15034480
fbshipit-source-id: 74d0830c686c8863fcede6e57404aec3f0a58ea1
Summary:
Python's `next()` can raise the `StopIteration` exception, unlike Rust's `next`
which just returns `None` instead.
Fix it by providing a default value `None`.
Reviewed By: singhsrb
Differential Revision: D15008773
fbshipit-source-id: df885c63b8130ceac38f86c89f2547dde2d519ba
Summary:
The way this command was implemented before this change would collapse
existing case collisions into a single value of the `lowerdirlist` dict.
The value that was chosen would be dependent on the traversal ordering.
If this value would be equivalent to the newly-introduced file, we would
miss the collision.
Reviewed By: markbt
Differential Revision: D14971701
fbshipit-source-id: d352e96e512154d92fe6bc49dd76aec63b954fef
Summary:
The "hg log" implementation chooses to not use the "follow" revset when logging
a directory, but use "_matchfiles" instead. In an upcoming change, we'd like
"follow" to handle directories so fastlog only needs to patch the "follow"
revset.
The "follow" revset can take a directory pattern just fine. The problem is
"follow" will follow *every* file inside the specified directory, which is
quite expensive.
For now, I just moved the "_matchfiles" fallback path to "follow" so when it
detects there are too many files to follow, it will switch to "_matchfiles"
directly.
In theory, tree manfiest repos would have "tree manifest" infomation that speed
up "follow" on a directory. But that's a bigger change, and it's probably very
slow in our setup because our trees are lazy.
This changes some behaviors subtly, as reflected in tests:
- `-f path` can use DAG range instead of rev range, which is a good thing as
rev range does not make much sense to end-users. This removes a "BUG" in
test-commit-amend.t
- `-f dir` can follow renames if the directory contains just a few files.
This looks like a good thing, and is reflected in `test-log.t`.
Reviewed By: sfilipco
Differential Revision: D14863134
fbshipit-source-id: 99ddff46d43f63ce03dc7bf005e3ac1cb9b39d03
Summary:
With upcoming changes, I noticed `limit(reverse(:.) & follow("path:fbcode/scm/hg"), 10)`
is much slower than `limit(reverse(::.) & follow("path:fbcode/scm/hg"), 10)`. I tracked
it down to the fact that spanset introduces a lot of unnecessary checks. Optimize it
by avoid using spanset in this case.
The revset pattern is used by `hg log`, the `reverse(:.)` part is to "define" the
order. Perhaps we sould replace it with `reverse(::.)`. But that's a BC change that
might have some unwanted side effects.
Reviewed By: sfilipco
Differential Revision: D14863135
fbshipit-source-id: 6ba8a02b58e1109bdf8370f03965a3b302cba6c0
Summary: `log` itself does the interpolation, so don't do it in advance.
Reviewed By: quark-zju
Differential Revision: D14941862
fbshipit-source-id: 6885202cfbff4ce0310d68bb1676369c3ef64c53
Summary:
This diff adds args escaping using single quote symbol before sending them to hooks.
Before all arguments where joined by space symbol " " which was producing incorrect result when argument itself contains space symbol.
Reviewed By: markbt
Differential Revision: D14799188
fbshipit-source-id: df5a4324d138515a4b881df96f2991de03df7a5b
Summary:
We should update the builder for Key to take a repo path. We could build
the key directly using the default struct constructor but representing
the two constructors as functions is more clear.
Reviewed By: quark-zju
Differential Revision: D14877543
fbshipit-source-id: 328906521cdbad535e28df22fea82f21e8b5410a
Summary:
We currently send perf traces to the blackbox, but we also want to log
them to our metrics. This configures hg to log the perf trace as a sample. Later
diffs will configure our wrapper to route these samples to manifold.
Reviewed By: mitrandir77
Differential Revision: D14881308
fbshipit-source-id: 07690f9af9fe14279a9ebf5089548c5880cba45d
Summary:
Autorels attempts to detect the scenario where `P -> Q` and `X -> Y` are
being added, and there already exists a `P -> ... -> X` relationship.
In this case it will create a `Q -> Y` "copy" marker to express the fact
that `Q` should be copied.
However, this also triggers in the case where `Q == Y`, creating a revive
marker for `Q`.
Normally this is benign, as Q is probably visible anyway, however when there
are two commits associated with a diff that has been landed, pullcreatemarkers
can create two markers: `P -> L` and `X -> L`. Since P and X are for the same
diff, there probably exists a `P -> ... -> X` relationship, and so autorels
attempts to make an `L -> L` marker. This fails because L is public.
Differential Revision: D14891063
fbshipit-source-id: 3f076a003508dd7b7d17e3eb7cdaeb8ac09e6b15
Summary:
The `subonly` option in the command decorator indicates that a command must be
called with a subcommand. Document this in the decorator documentation.
Differential Revision: D14876782
fbshipit-source-id: d121f94437e47cad2a7f3abe0faac300792c1c76
Summary:
Add support for explicit visibility tracking in commit cloud sync.
This means commit cloud reads the visibleheads and syncs these with the commit
cloud heads directly, removing the source of problems where obsmarkers disagree
on different hosts.
Commit cloud requires that the ordering of heads is maintained to get stable
ordering of new commits. Update the visibleheads tracking to maintain
ordering, rather than using sets.
Finally, the calculation of the replacement node was slightly off. This was
revealed in the new test case that is being added, so it is also fixed.
Differential Revision: D14876266
fbshipit-source-id: fe5b6bffd196d3bd74e7582e29484969495eac8e
Summary:
The computation of whether a commit is obsolete or not can be improved.
We can cache which commits are known to not be obsolete.
We can also have a cache for each filter type so that we only need to compute
obsolete nodes that match the filter.
Finally, when we need to compute all obsolete commits, we can start by looking
for commits which are made obsolete by only their closest successors, and then
filling back obsolescence to the predecessors of these obsolete commits.
Reviewed By: DurhamG
Differential Revision: D14858655
fbshipit-source-id: 1d03e214ad878ecb6ae548f80373702e2a184146
Summary:
Rather than implicitly upgrading or downgrading a repo based on the
`visibility.tracking` config option, add a new `hg debugvisibility` command to
do this explicitly.
Reviewed By: DurhamG
Differential Revision: D14871231
fbshipit-source-id: 73f4648408b3eca9ac12bd77e54d2d37ee342069
Summary:
Record the commit predecessors and the mutation operation in the commit loginfo
so that it can be logged to telemetry.
Reviewed By: quark-zju
Differential Revision: D14798032
fbshipit-source-id: 9c4ac1a4df3c91087c776d1f8e5fca94713b0390
Summary: Make the batch size of data and history requests independently configurable, since data responses are typically much larger than history responses (since the former contains actual file data whereas the latter is only metadata).
Differential Revision: D14859686
fbshipit-source-id: c87c31f3e6611a55ae712e7f0ed9bb392d31a579
Summary: Use the curl multi interface to fetch multiple batches of files or history entries concurrently.
Differential Revision: D14718547
fbshipit-source-id: c5a740c7e9106b719e825540f8182be31a72bae7
Summary: Allow users to configure which HTTP client backend to use for the Eden API via the `edenapi.backend` config option. Valid options are `curl` and `hyper`, with `curl` being the default.
Reviewed By: quark-zju
Differential Revision: D14657871
fbshipit-source-id: 7a9972d2380fbbd5ed62d1accae764dc03ca4c29
Summary:
Add a new Eden API client based on libcurl (via the rust-curl crate). This should help us work around issues with Hyper.
This implementation is based on curl's "easy" API, and is intentionally naive. I intend to update it to use curl's "multi" API to send several concurrent HTTP requests per operation in a later diff.
Differential Revision: D14656756
fbshipit-source-id: 1f71074506844104f0f3237023b38317a7f41979
Summary: This is a stop gap measure while we move internal path encodings to UTF-8.
Reviewed By: quark-zju
Differential Revision: D14791761
fbshipit-source-id: e4d5a845aa4f28ed0744cf80021fd1446f3d6129
Summary: `commitctx` takes error as a named parameter shadowing the module import.
Reviewed By: quark-zju
Differential Revision: D14805901
fbshipit-source-id: 359a6d19d6a08b3c65ebf1af8a5e5baaec6711a2
