Summary:
The existing query to establish HgChangesetId on the path to FileContentMetadata for LFS validation is quite complex, using HgFilenode linknodes.
This change adds an optional edge from BonsaiHgMappingToHgBonsaiMapping that can be used to simplify the LFS validation case and load less data to get there.
Reviewed By: mitrandir77
Differential Revision: D26975799
fbshipit-source-id: 799acb8228721c1878f33254ebfa5e6345673e5d
Summary: Comment can go as we're using SmallVec now.
Reviewed By: farnz
Differential Revision: D26987009
fbshipit-source-id: f520c90b3a210283d139ba1de8ce140e12a4f875
Summary:
Add a way to register an IO time series showing total network I/O, and register
download progress bars for requests.
Reviewed By: andll
Differential Revision: D26853750
fbshipit-source-id: 42c4ab9724c60db9612a2bc419ca3bceaa667647
Summary:
It turns out there are multiple users sending requests bypassing the
HttpClient, like the LFS in revisionstore, or the segmented changelog
clone.
Requests bypassing HttpClient means HttpClient event callbacks do not
have a chance to insert progress and bandwidth monitoring. So let's
add another callback that can capture what HttpClient misses. This would allow
us to get proper progress bars of revisionstore LFS and segmented clone without
changing their code.
Reviewed By: andll
Differential Revision: D26970748
fbshipit-source-id: 5133bc6f9eeb14a6d2944d253bc66cefd49c83c5
Summary: Expose Rust's progress model so Python can operate on them.
Reviewed By: andll
Differential Revision: D26886283
fbshipit-source-id: 843de4cd2d8d22aba014ee097b0fee2feeb6ee43
Summary: Add a simple way to render progress into a multi-line string.
Reviewed By: andll
Differential Revision: D26853751
fbshipit-source-id: 4f1de55e7bb03f607d683eff16e035aa5d1476c1
Summary:
Add a struct to "register" progress data for Rust to render them.
Note: The "registry" only tracks the data. Rendering will be
implemented separately.
Reviewed By: andll
Differential Revision: D26615606
fbshipit-source-id: affa663660bd52a2583d40e3b28f0b65480851a3
Summary: Add an API to render the time series samples into ASCII graph.
Reviewed By: andll
Differential Revision: D26836633
fbshipit-source-id: 9c7a757e46c28c810fb3e0671a775fde16318f54
Summary: This could be used for showing overall statistics
Reviewed By: andll
Differential Revision: D26886280
fbshipit-source-id: a52f057dbbebb441d0eee14860275f2690c7a3a3
Summary: Add an API to render the time series samples into an array that can be further turned into an ASCII graph.
Reviewed By: andll
Differential Revision: D26615170
fbshipit-source-id: 4a2f178869c235e7dda3edef7930a6e04bc4bda3
Summary: Continue with last change. Add a time series type that keeps samples.
Reviewed By: andll
Differential Revision: D26615171
fbshipit-source-id: 5dcc775820d782ac502d84b6af5e270f2a9072ee
Summary:
Going to add some kind of "time series" graph based on periodical sampling.
Add the sample structure for IO with some simple math helpers.
Reviewed By: kulshrax
Differential Revision: D26615173
fbshipit-source-id: 4d610f435a3c7913e8bb31a8de0738ffb3de1468
Summary:
Going to add some kind of data model definitions for pure Rust logic.
Use a dedicated crate so progress model and rendering are separate. If the
rendering logic becomes bloated somehow, it won't affect the data models.
The idea is that only application-level logic like `hgcommands` care about
rendering. Other use-cases only care about pure progress states.
Reviewed By: andll
Differential Revision: D26836634
fbshipit-source-id: 5222d2f9fb4894bd246c62ad48e1c5fc982e2fa6
Summary: A recent diff modified this test and accidentally introduced a mismatch with Windows. Let's glob out the different path separators.
Reviewed By: quark-zju
Differential Revision: D26997063
fbshipit-source-id: 3cbe1f1fa748f8282fe16ee3d38f23519c87f6b9
Summary: With `ui.pushbuffer`, `out` can be `ui`, and it does not have `isatty()`.
Reviewed By: DurhamG
Differential Revision: D26992865
fbshipit-source-id: 1725291ba5ab3b7ccd8702fbb9df7213a05e3350
Summary:
errors are nicer - panic show a huge stack trace, and it takes a long time to
get coredump
Reviewed By: krallin
Differential Revision: D26984264
fbshipit-source-id: 2fa6aca32544d63f0c4264cdbad56eaf55d71955
Summary:
If a filename passes this hook it should be checkoutable on windows.
Unfortunately it's not the case now - we're missing the check for invalid
characters. Although this list might be redundant and some of chars might be
already banned by other hook let's make this hook a place for all
windows-specific filename checks.
Reviewed By: farnz
Differential Revision: D26979418
fbshipit-source-id: f1fa685b9e7e5413d8030d18bc083458b6a148e1
Summary:
Previously we referred to the config location as the repo_path or
repo_dir. In an upcoming diff we'll support NoRepo configuration, so let's
rename this to config dir and support using cache_dir as a config dir if there
is no repo. That code path isn't actually used in this diff though.
Reviewed By: kulshrax
Differential Revision: D26801061
fbshipit-source-id: 72cd672f65ca10821882ee9124fd4a293ead7257
Summary:
Previously we assumed there was always a repository. In an upcoming
diff we'll support configuring Mercurial without any repository. To support that
let's add a representation of NoRepo to the dynamicconfig structure and update
all uses to use that.
Nothing will currently create a NoRepo, but that will come in a later diff.
Reviewed By: kulshrax
Differential Revision: D26801060
fbshipit-source-id: d8e9066c865921f45e068c799ac8acb8eec32acd
Summary:
Pure Rust commands weren't loading dynamicconfigs correctly because the
validation was happening in Python. This diff moves it down into Rust so that
all config loading gets the same validation.
Also removes the hard coded list of files to validate. I'll add this to
configerator to make it easier for us to edit.
Also removes the configs.validatedynamicconfig option. Validation is on
everywhere and should just be on by default.
Reviewed By: kulshrax
Differential Revision: D26680075
fbshipit-source-id: f206198154801f655b4b277cdb22a728d0004b5f
Summary:
Previously, only --config configs were pinned in the uiconfig. "pinned"
means that no matter what values were loaded underneath, those pinned values
would not be changed. This allows CLI specified configs to take precendence
regardless of what and when config files are loaded. --configfile configs were
not pinned in the same way, despite it seeming like they should be pinned. In
fact, during clone we "reload" the config, which causes the --configfile value
to be lost.
Let's make --configfile pin all of it's configs as well.
This has a bit of an unfortunate side effect. When we do clone via hg-clone we
pass --configfile /etc/mercurial/repo-specific/$REPO.rc so the clone has the
right configuration. This diff means that those values are now loaded in a
pinned state, so dynamicconfig cannot overwrite them and the values cannot be
deny-listed.
The longterm solution to this would be to stop using --configfile during clone,
and instead use --config remotefilelog.reponame=$REPO and allow dynamicconfig to
generate the rest. But for now it's probably fine to let them be pinned.
Reviewed By: quark-zju
Differential Revision: D26677599
fbshipit-source-id: 2837a5b5d14bb42b49eaf9d1d0019f2ea0620a9e
Summary:
We've had a few issues recently where clones failed because of
unexpected config load ordering. The main problem is that we can't load repo
configs until the repo is created and the .hg/hgrc created. This happened rather
late in the process, for instance it happened after the source connection was
created, so no repo-specific dynamicconfigs could affect the source connection.
This diff moves the destination repo creation earlier in the clone process,
which will load the appropriate dynamicconfigs before we connect to the clone
source. This removes the last usage of applydynamicconfig, which will be deleted
in the next diff.
Reviewed By: quark-zju
Differential Revision: D26676519
fbshipit-source-id: 9a0f0b2ac0d9f19b8bb6fbaf26b4a5e7fb803399
Summary:
We've had a few issues recently where clones failed because of
unexpected config load ordering. The main problem is that we can't load repo
configs until the repo is created and the .hg/hgrc created. This happened rather
late in the process, for instance it happened after the source connection was
created, so no repo-specific dynamicconfigs could affect the source connection.
This diff moves basic repo creation (the directory, the .hg, and the .hg/hgrc)
earlier in the repo creation process and loads dynamicconfigs before proceeding.
This eliminates the use of applydynamicconfig in the localrepo constructor.
The next diff moves repo creation earlier in the clone process to then benefit
from this, and removes the final use of applydynamicconfig, thus preventing
config load ordering issues.
Reviewed By: quark-zju
Differential Revision: D26676520
fbshipit-source-id: 8784f2483909a50e8be9eb1a7adf03e8807ef076
Summary: These were generally useful when debugging native checkout.
Reviewed By: quark-zju
Differential Revision: D26955400
fbshipit-source-id: 967a4fa2d831b8b060409a5f7be31a1416c1ba63
Summary:
Add the `focusedbranch` revset. This expands to the current draft branch, plus
any commits that are related to the branch via commit mutation and their
descendants.
This can be used as the revset for `hg smartlog` to give a more focused smartlog
that shows only the changesets relevant to the current stack.
Reviewed By: quark-zju
Differential Revision: D26852107
fbshipit-source-id: 9723935bf3bf900f8e109d4f507ae1db6627807e
Summary:
Since an EdenFS mount can only be mounted in a single place, we don't need to
support the NLM protocol, thus let's inform Linux to not use it.
Reviewed By: kmancini
Differential Revision: D26771237
fbshipit-source-id: bc534a938ad6348bf10a553c6c4f283f043da4f5
Summary:
As it's name implies, this RPC is used to rename files. It's not clear whether
all the error cases that the spec specifies are properly covered, but future
tests can uncover this.
Reviewed By: kmancini
Differential Revision: D26771235
fbshipit-source-id: cad1065a5277e2ab169dd34c7d485d6a4cdd4b76
Summary:
This is pattern that is repeated in several functions, let's only have one
function to make the code easier to read.
Reviewed By: kmancini
Differential Revision: D26771236
fbshipit-source-id: 64a68e90eafcea85f850374751ae7bf34f98f118
Summary: This merely adds the types needed for the RENAME RPC.
Reviewed By: kmancini
Differential Revision: D26771238
fbshipit-source-id: 7b9db7b46ffba2d7a906d0e2b60e24df0b5b055d
Summary:
The SETATTR RPC allows for changing various attributes of the file, like it's
mode, uid, gid, etc. The one piece of the NFS RFC that isn't implemented is
that NFS allows for a client to pass a ctime to the server that it needs to
check prior to setting the attributes. This is done to avoid concurrent
operations on the file conflicting with each other. This is not implemented for
now as Mercurial appears to not be using it.
Reviewed By: kmancini
Differential Revision: D26760073
fbshipit-source-id: 3474665fcf1b089ef6f7de4a6c45a26ef324240e
Summary: D26781269 (7ed5a54640) removed the test, but didn't remove the running reference.
Reviewed By: HarveyHunt
Differential Revision: D26978336
fbshipit-source-id: baf521632efd76c7977fb1b1c0b02e18d9a3cd43
Summary:
Deleted files manifests are immutable, and their maps are stored in sorted
order, so we can use `SortedVectorMap` to load them more efficiently.
During derivation, maps are constructed out of order, so BTreeMap continues
to be used there.
Reviewed By: mitrandir77
Differential Revision: D26275362
fbshipit-source-id: 0d159f4f53ff3ec345ac9bd34a70018e151d4e37
Summary:
BonsaiChangesets are rarely mutated, and their maps are stored in sorted order,
so we can use `SortedVectorMap` to load them more efficiently.
In the cases where mutable maps of filechanges are needed, we can use `BTreeMap`
during the mutation and then convert them to `SortedVectorMap` to store them.
Reviewed By: mitrandir77
Differential Revision: D25615279
fbshipit-source-id: 796219c1130df5cb025952bb61002e8d2ae898f4
Summary:
Unodes are immutable, and their maps are stored in sorted order, so we can
use `SortedVectorMap` to load them more efficiently.
Reviewed By: mitrandir77
Differential Revision: D25615276
fbshipit-source-id: ff8c93e8cde50aa7d3565550c0eade38b67017ca
Summary:
ChangesetInfo is immutable and its maps are stored in sorted order, so we
can use `SortedVectorMap` to load them more efficiently.
Reviewed By: mitrandir77
Differential Revision: D25615278
fbshipit-source-id: 2078adeddc8bd049985fb4efafe3090858a1bc0a
Summary:
Thrift maps are stored in sorted order, so we can use `SortedVectorMap` to
load them more efficiently.
Reviewed By: mitrandir77
Differential Revision: D25615277
fbshipit-source-id: 509a9d63df6a6a793a4b0b2935e9ed86e7c6eaaf
Summary:
Switch to using smallvec::SmallVec for the thrift types that contain small
amount of binary data.
Reviewed By: farnz
Differential Revision: D26461215
fbshipit-source-id: 8751a14bebdac3ea59fbd95197aa489e9f8e1d87
Summary:
Add a microbenchmark for deriving data with large directories.
This benchmark creates a commit with 100k files in a single directory, and then
derives data for that commit and 10 descendant commits, each of which add,
modify and remove some files.
Reviewed By: ahornby
Differential Revision: D26947361
fbshipit-source-id: 4215f1ac806c53a112217ceb10e50cfad56f4f28
