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
Summary: Rename this benchmark to a specific name so that we can add new benchmarks.
Differential Revision: D26947362
fbshipit-source-id: a1d060ee79781aa0ead51f284517471431418659
Summary:
S3 blobstore is sensitive to the number of open connections and it causes perf
problems. Let's add a way to limit the number of simultaneous open connections.
Also see D26911520
Reviewed By: krallin
Differential Revision: D26911679
fbshipit-source-id: 1e3e4922b26d0a29c94c89b4aa76b9b5928effe6
Summary:
When generating hg changesets from git changesets we can run into a situation
where two git commits are almost completely identical with the exception of
committer field. Currently it results in us generating identical mercurial
changesets for different bonsai changesets, and this is something we do not
allow.
Let's do the same thing as hggit does i.e. record committer field in extras if
committer is different from author.
In case of ambiguities (i.e. committer extra is already set, or committer date is set but committer name is not) I opted for returning an error instead of trying to guess what the correct field should be.
Reviewed By: farnz
Differential Revision: D26867740
fbshipit-source-id: 6271e2f7ad421bec296c60ff211723c2162878c6
Summary:
Similar to `output()`, and `error()`, provide a `progress()` to support setting
progress without needing `&IO`.
Reviewed By: andll
Differential Revision: D26886278
fbshipit-source-id: a54563a9cf1d9d1cdb9dabe945aeb5ed1d84e8fb
Summary: Make sure the progress is not hidden because of buffering.
Reviewed By: singhsrb
Differential Revision: D26886277
fbshipit-source-id: d44e48e67b4529a181dd36c30e92608654d8fea6
Summary:
Written by Martin von Zweigbergk at https://phab.mercurial-scm.org/D9551,
or https://www.mercurial-scm.org/repo/hg/rev/bdc2bf68f19e.
He suggested it and it's a useful feature. I did minor compatibility changes
(encoding, avoid rev numbers, foo_bar -> foobar).
Original commit message:
I use 3-way conflict markers. Often when I resolve them, I manually
compare one the base with one side and apply the differences to the
other side. That can be hard when the conflict marker is large. This
patch introduces a new type of conflict marker, which I'm hoping will
make it easier to resolve conflicts.
The new format uses `<<<<<<<` and `>>>>>>>` to open and close the
markers, just like our existing 2-way and 3-way conflict
markers. Instead of having 2 or 3 snapshots (left+right or
left+base+right), it has a sequence of diffs. A diff looks like this:
```
------- base
+++++++ left
a
-b
+c
d
```
A diff that adds one side ("diff from nothing") has a `=======` header
instead and does not have have `+` prefixed on its lines. A regular
3-way merge can be viewed as adding one side plus a diff between the
base and the other side. It thus has two ways of being represented,
depending on which side is being diffed:
```
<<<<<<<
======= left
contents
on
left
------- base
+++++++ right
contents
on
-left
+right
>>>>>>>
```
or
```
<<<<<<<
------- base
+++++++ left
contents
on
-right
+left
======= right
contents
on
right
>>>>>>>
```
I've made it so the new merge tool tries to pick a version that has
the most common lines (no difference in the example above).
I've called the new tool "mergediff" to stick to the convention of
starting with "merge" if the tool tries a regular 3-way merge.
The idea came from my pet VCS (placeholder name `jj`), which has
support for octopus merges and other ways of ending up with merges of
more than 3 versions. I wanted to be able to represent such conflicts
in the working copy and therefore thought of this format (although I
have not yet implemented it in my VCS). I then attended a meeting with
Larry McVoy, who said BitKeeper has an option (`bk smerge -g`) for
showing a similar format, which reminded me to actually attempt this
in Mercurial.
Reviewed By: DurhamG
Differential Revision: D26947920
fbshipit-source-id: 8b4446862897ff9a6dfdf5a2e35617d4db09e883
Summary:
Add a check to ensure the `into_vec()` fast path do not take the full vec if
the `Bytes` is sliced.
Reviewed By: andll
Differential Revision: D26966453
fbshipit-source-id: 538dfb8ca2f01a46d1ede7b98b7f0a30fc7a786e
Summary:
VS Code is seeing issues where they are accidentally triggering
multiple hg status calls, which trigger multiple expensive watchman queries.
While they're trying to track down why this is happening, they'd like a config
that would enable hg to only run one of their status calls at a time.
Reviewed By: quark-zju
Differential Revision: D26931193
fbshipit-source-id: 3b36ac06217bb506110b8d708d4a74378245d5bb