Summary:
The Rust progress bars now integrates with hg-http and all requests get
progress bars for free. There is no need for a separate bar.
Reviewed By: andll
Differential Revision: D26970747
fbshipit-source-id: c5e59c745e75a93e5da0541baab21c3f23dc1322
Summary:
Render the progress bars in a Rust thread.
Also make it compatible with traditional Python progress bars (not the most efficient way because the Python still have its own progress thread, but the code change is minimal).
Reviewed By: andll
Differential Revision: D26886282
fbshipit-source-id: ad1f862ced278cc1cb90c37f576eb05f52a50b13
Summary: 100 and 5k seems too small - requests are too frequent.
Reviewed By: andll
Differential Revision: D26886276
fbshipit-source-id: cb5cce1111120f8a437fbc8c60906940588f38bc
Summary:
Split `dispatch()` into 2 parts: config parsing and command execution.
This allows callsite to do extra work based on the config before running the
command.
Reviewed By: andll
Differential Revision: D26853749
fbshipit-source-id: 459918b43341f7e14df6958056b6e07453bb691b
Summary: This method should be preferred to use from python binding. It is similar to block_on but allow to interrupt future on Ctrl+C
Reviewed By: quark-zju
Differential Revision: D26894586
fbshipit-source-id: 02d8fbb2f9c4d9e585f8fbee51bfc400c402d0d2
Summary:
During sparse profile change, there might be a case when file has changed between checkouts, and also is added due to sparse profile change
Currently this would lead to creating duplicated update action that would waste resources. This diff deduplicates such action
Reviewed By: quark-zju
Differential Revision: D26953657
fbshipit-source-id: ccd9084cc3984ac0692ee6178fce018a94cd56e7
Summary:
Current store implementation returns value that may contain matadata.
We need to strip it before writing out file to disk
This is not going to be a problem with new Eden API, but it is not erady yet and rolling it out may take time
So in order to start testing native checkout now, we are incorporating metadata removal in the checkout code
Reviewed By: quark-zju
Differential Revision: D26953658
fbshipit-source-id: 05d8be55bb96e7c3162594498ef0b9944b422c90
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:
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:
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
Summary:
RepoError prints `!` at the end of `abort:`. This maintains the old behavior
and should fix test breakages like:
$ hg clone 'ssh://fakehost|touch%20owned/path'
destination directory: path
- abort: no suitable response from remote hg!
+ abort: no suitable response from remote hg
[255]
Reviewed By: DurhamG
Differential Revision: D26964146
fbshipit-source-id: 2e6d095b82ce1e2e23a353cf8f06ae844ee872d7
Summary:
There are a report of slow smartlog that tries to show 8M nodes in `draft()`.
That is an issue after the automatic bookmark clean up, and the visible heads
incorrectly make large amount of commits draft.
Reviewed By: kulshrax
Differential Revision: D26934644
fbshipit-source-id: 0c0890f8eaf1422dab9c03159a419800ae7247ca
Summary:
We're seeing issues where watchman is frequently having to recrawl the
repository due to fsevents getting dropped. We believe this is caused by large
amounts of IO, but we're not sure from what process (buck? hg? arc? ide?). Let's
add some logging to Mercurial to estimate when a checkout triggers a recrawl.
Reviewed By: xavierd
Differential Revision: D26931996
fbshipit-source-id: 0026c792f0ec216cb3e98424da819c4c6e925072
Summary:
Visible heads can overlap with scratch remote bookmarks, and in bad cases
(before D26792731 (7a759b6075)), overlap with public remotenames.
When we remove remotenames we need to remove referred nodes in visibleheads
too so we don't end up with massive draft commits.
Reviewed By: DurhamG
Differential Revision: D26954215
fbshipit-source-id: 91010e6608d0150ecf374ce31705e97712154b27
Summary:
Scratch remote bookmarks are considered draft() and were not cleaned up.
Practically there are users with 100+ scratch remote bookmarks. Let's
clean them up too.
Note the commit still remain visible, which will be fixed in upcoming
diffs.
Reviewed By: DurhamG
Differential Revision: D26954216
fbshipit-source-id: e84f99e4e914f0c5169583fc9f60084f23664e02
Summary:
Current `block_on_future` implementation is not safe, as it does not panic on nested calls. Nesting `block_on_future` calls causes starvation of tokio scheduler processes and eventually will lead to deadlock if nested too many times
This diff simply calls `block_on_exclusive` from `block_on_future`. When we see that this does not cause problems we can simply remove `block_on_future`
Reviewed By: sfilipco
Differential Revision: D26899522
fbshipit-source-id: 93794bf2c5908421691dfb094d1807266c9ecd8d
Summary:
Johan Schuijt-Li found they are broken on some CI hosts.
(But other store paths seem okay, which might indicate the fsync list is effective)
Reviewed By: DurhamG
Differential Revision: D26950101
fbshipit-source-id: e3bcd3f77636325be9e9ce8dfded8b17ec68f436
Summary: This is intended to be used in Sandcastle / OnDemand use-cases to provide a cleaner state.
Reviewed By: DurhamG
Differential Revision: D26924711
fbshipit-source-id: a37d24a10c99d953e2af842f729ef634cbb2e2f9
Summary:
Some merge-tools, like kdiff3, are configured to fix end of line stuff.
This code breaks in Python 3.
Reviewed By: quark-zju
Differential Revision: D26932815
fbshipit-source-id: 7601d53616e50961b89bbc4b0340a9fb672293ef
Summary: This API will be used to spawn tasks in the runtime.
Reviewed By: andll
Differential Revision: D26615607
fbshipit-source-id: 6b9892fad755bbe8feb775e9dad457697b2ea1b7
Summary: hgsql can only use traditional revlog. Disable changelog migration for it.
Reviewed By: kulshrax
Differential Revision: D26891252
fbshipit-source-id: 36c5a448d4fcad15b3415e4534448a945f6d0b4b
Summary: We weren't passing a repo path when initially loading the repo's config in `clidispatch`. This meant that the resulting `ConfigSet` didn't contain values from the shared-repo `.hgrc.dynamic`. Evidently, some other code path in Python would eventually add these values, but this meant that pure-Rust commands could not see config values set via dynamicconfig. Passing the path fixes the problem.
Reviewed By: DurhamG
Differential Revision: D26508980
fbshipit-source-id: 65f187d18098a08c81325e78cb02a8ed854c739a
Summary:
See the previous diff for motivation. This removes bookmarks that are
ancestor of master, too. This is important in practice.
Reviewed By: DurhamG
Differential Revision: D26889412
fbshipit-source-id: 255722ed5b486e88ef56e7e378fae3f1113d5fbe
Summary:
The auto cleanup was conservative. It keeps `::draft()`. But that means
ancestors of public commits are not cleaned up. Not all release branches
branch off the master branch.
Reviewed By: DurhamG
Differential Revision: D26889413
fbshipit-source-id: c6a8e3f32cf1f7d2ffe74b7ecd183f4e583949bb
Summary:
This allows for errors raised in these cases to be retried. Most notable is
the timeout error.
Reviewed By: johansglock
Differential Revision: D26855441
fbshipit-source-id: 6137ed1755072d43dbdd25fa092ddb21c8669aa3
Summary:
No timeout is set up by default so the process wait forever when reading bytes
in cases where the connection is lost somehow.
Reviewed By: johansglock
Differential Revision: D26855443
fbshipit-source-id: d741f73e7186fe862f3d78a806f3219c2cbe7e0a
Summary:
Abort one of the most general exceptions in Mercurial. In theory it should be
something that isn't handled. We can say at least that it shouldn't be retried.
For thing that may be transient it is better to use a different type of
exception. NetworkError is something is checked and retries in a few places so
that seems like a natural candidate.
Reviewed By: johansglock
Differential Revision: D26855444
fbshipit-source-id: f15c723293a416b5f44a6592927e3500f3b0b7d5
Summary: Timeouts are another class of errors that are relevant.
Reviewed By: johansglock
Differential Revision: D26855442
fbshipit-source-id: 8ebb83714fa3d7a2f4efcbed8bd512c98301b49d
Summary: The goal is to reduce load on tokio scheduler by using threads & channels instead of spawning new task every time
Reviewed By: DurhamG
Differential Revision: D26801249
fbshipit-source-id: a8d9accc721c7ffc981fd538c06ab8cbd908f715
Summary:
AsyncVfs provides async vfs interface.
It will be used in the native checkout instead of current use case that spawns blocking tokio tasks for VFS action
Reviewed By: quark-zju
Differential Revision: D26801250
fbshipit-source-id: bb26c4fc8acac82f4b55bb3f2f3964a6d0b64014
Summary: This function is now internal details of vfs, and is not used outside of it. Making it private so it won't be accessed outside
Reviewed By: quark-zju
Differential Revision: D26801251
fbshipit-source-id: 03434e235978fa0745128d90ea0c5975ea662ff1
Summary: This diff removes the split between manually managed and autocargo managed Cargo.toml files in `eden/scm/lib`, now all files are autogenerated.
Reviewed By: quark-zju
Differential Revision: D26830884
fbshipit-source-id: 3a5d8409a61347c7650cc7d8192fa426c03733dc
Summary:
The GitTreeDict throws when we're trying to remove the root directory but there
are valid situations where the Tree becomes briefly empty. One of such is a
commit where all the files in the repo are moved. We process the deletions
first. Then we proceed with additions.
Reviewed By: DurhamG
Differential Revision: D26778717
fbshipit-source-id: 6caa1709ff2c5e78d4745336b0527af4bb20ec60
Summary:
Native checkout avoids the initial large prefetch, and instead does
small batch prefetches and immediately writes them to disk. This will prevent
the issue where data in the cache is evicted before it's used and has to be
redownloaded in a non-batch fashion later.
In a future diff, using native checkout will also allow us to serialize and
deserialize it's CheckoutPlan, so we can make clones resumable.
Reviewed By: quark-zju
Differential Revision: D26825773
fbshipit-source-id: 6fde90cd7578f6af5fdd4ac78004f7f63af4f287
Summary: the list of configured default selective pull bookmarks are actually related to the hoist namespace I think when we consider what is protected and what is not.
Reviewed By: quark-zju
Differential Revision: D26814708
fbshipit-source-id: 566f363f1e6b88dd2ebc6e33cfb6eba596493988
Summary:
On POSIX systems it's a good practice to fsync directories to ensure metadata
about a file is properly written.
Reviewed By: DurhamG
Differential Revision: D26822211
fbshipit-source-id: fca10c702b480f22020ad184eb55c8879999f0ee
Summary:
Typical mistake of `reposetup` - the `repo` object might be remote and lack of
local repo methods.
Reviewed By: DurhamG
Differential Revision: D26822960
fbshipit-source-id: 54fb95c51b09ef5021b0a10a93b4509e7aa4a115
Summary:
I moved the source of the sphinx project to newdoc for newdoc/dev.
I updated the sphinx config for markdown to something that works for recent
versions.
PNG images rendered better than SVG for me.
I moved the TARGETS to newdoc.
Reviewed By: quark-zju
Differential Revision: D26801426
fbshipit-source-id: 3ae51e886d27f848f0f6a48c96056da607d8da45
Summary:
Mercurial uses Makefile here to build stuff. We want to track Makefile under
scm.
Reviewed By: quark-zju
Differential Revision: D26802165
fbshipit-source-id: 1fe8db13d50c07a6a0681180959eba22eaf8d486
Summary:
The previous fix D23357655 (d60e80796a) actually only fixes py2 absorb -i. On Python 3,
`b"-"[0]` is `45`, not `b"-"` like Python 2. Fix it again using `b"-"[0:1]`.
Reviewed By: singhsrb
Differential Revision: D26805315
fbshipit-source-id: 07ca850373a6bc49b561466ead478024631ce051
Summary:
Memcache is dogslow to initialize, taking >30s on debug build. As a
consequence, this slows down every single test by that amount time, with the
guarantee that no blobs will be found in memcache, ie: a total waste of time.
On release builds, Memcache is significantly faster to initialize, so let's
only disable initializing Memcache for debug builds only.
Reviewed By: fanzeyi
Differential Revision: D26800265
fbshipit-source-id: 8b393c603414de68268fdadb385de177e214a328
Summary:
Adds a new hg py3 windows package to hgbuild for publishing. Currently
the tests don't run. I'll do that next.
Reviewed By: quark-zju
Differential Revision: D26768336
fbshipit-source-id: bd4533abbbc1e1c861aa9995b7a3868a7f6a1a22
Summary: Trigger the cleanup logic automatically if there are too many remote bookmarks.
Reviewed By: sfilipco
Differential Revision: D26802251
fbshipit-source-id: 1ab40c7be98c507865ea17001dc9775b6edf4446
Summary: This is handy to make the `sl` output cleaner.
Reviewed By: sfilipco
Differential Revision: D26802250
fbshipit-source-id: 1b74f3d9a42ab6b0780f07bec59b03a5cd0ea6a9
Summary:
Previously remotenames pointing to unknown commits are just ignored.
If key remotename like master is ignored, it can cause very slow operations
in pull, etc. Let's just raise an exception in this case.
Reviewed By: DurhamG
Differential Revision: D26800236
fbshipit-source-id: 13be4af5499da1b9098b4ff1a6ef41c54092824a
Summary:
Remove public heads when using Rust changelog backends. This should address
some issues seen in commit cloud sync.
This is done at the metalog commit time so we get the latest "remotenames" data for
accurate "public()" set calculation.
Reviewed By: singhsrb
Differential Revision: D26792731
fbshipit-source-id: 00b894fee9804740d664dad0ac47be564820da33
Summary:
The output encoding is used to render the graph log edges. With D26612487 (62ba7447f6), we
switched to Rust IO. The Rust IO requires UTF-8 data. So let's set
outputencoding to UTF-8.
Reviewed By: sfilipco
Differential Revision: D26799551
fbshipit-source-id: aa3e6420067d7c75bef47448e12e48f4cef56a84
Summary:
We have configs that affect peer connections, like help.tlsauthhelp,
that are considered "repo-specific" configs now that they come from
dynamicconfig. Unfortunately repo-specific configs are removed from the ui when
copying it for use in a new remotepeer.
Let's add a few config sections to the allow list for what can go in a remote
peer ui. I have a task for making even repo-less commands load the standard
config, so in the future we can have these new peer objects use the standard
repo-less config, which will remove much of the need for maintaining this
allow-list.
Reviewed By: singhsrb
Differential Revision: D26784364
fbshipit-source-id: 30d9292e48b0f27ce7f4d4904ff6d5ff8dcaf069
Summary:
Provide a method that does pure serialization from (name, node) pairs to the
remotenames blob. This makes it reusable outside `vfs` or `repo` context.
Reviewed By: DurhamG
Differential Revision: D26707454
fbshipit-source-id: c45662922d337e31d17070e5f5828d47e23773b1
Summary:
sometimes in visible heads the hashes of the remote bookmarks are not the latest, so the filtration like it was initially implemented didn't work
if visible heads are polluted, it makes commit cloud operations slow but at least this correct check won't allow public heads to enter workspaces
moreover, after roll out it will fix already existing workspaces with public heads automatically by removing them from workspaces
also, this will allow our magic script to fix remote bookmarks in workspaces to work properly (debugfixcommitcloud), unfortunately now it can break a workspace if we remove bookmarks but not heads
cc quark-zju - could we fix the initial issue how the public heads can enter visible heads in some cases in pull logic? I have a repro if you are interested in.
Reviewed By: singhsrb
Differential Revision: D26778632
fbshipit-source-id: 05dbd4cd415911283ea66ae17772b8d3e458bbd7
Summary: EdenFS doesn't need the history, therefore let's not spend time prefetching it.
Reviewed By: fanzeyi
Differential Revision: D26767634
fbshipit-source-id: 7113f4ce79fdef5455a2bb238ab9d51b7339d8b6
Summary:
Parsing the remotenames (blob) into a list of name -> node pairs.
This makes it reusable outside `vfs` or `repo` context.
Reviewed By: DurhamG
Differential Revision: D26707457
fbshipit-source-id: e6c8bd9ff14d0fea9209c25b89fe733675da747e
Summary:
Use the new memctx.mirror and memctx.__setitem__ APIs. This simplifies the
code.
Reviewed By: DurhamG
Differential Revision: D26726474
fbshipit-source-id: 044616137b883ca250e6d84c0ecfcc70458ec07a
Summary:
Use the Rust tree matcher to rule out files that do not need dirsync quickly.
This should make codemod faster to commit.
I created 5000 files outside dirsync config in fbsource (with 494 lines of
dirsync config), and `hg add` them:
$ mkdir unused
$ cd unused
$ for f in `seq 5000`; do touch $f; done
$ hg add .
Baseline "status":
In [3]: %time repo.status();1
CPU times: user 111 ms, sys: 10.2 ms, total: 122 ms
Wall time: 148 ms
Before, dirsync overhead is ~8x "status":
In [1]: %time x.dirsync.dirsyncctx(repo[None])
CPU times: user 1.37 s, sys: 28.8 ms, total: 1.4 s
Wall time: 1.79 s
Out[1]: (<workingctx f23d7c84c5a7+>, set())
In [2]: %time x.dirsync.dirsyncctx(repo[None])
CPU times: user 1.07 s, sys: 8.41 ms, total: 1.08 s
Wall time: 1.11 s
Out[2]: (<workingctx f23d7c84c5a7+>, set())
After, dirsync overhead is ~1/2 of "status":
In [1]: %time x.dirsync.dirsyncctx(repo[None])
CPU times: user 203 ms, sys: 18.9 ms, total: 222 ms
Wall time: 245 ms
Out[1]: (<workingctx 8ff14e46c9d8+>, set())
In [2]: %time x.dirsync.dirsyncctx(repo[None])
CPU times: user 154 ms, sys: 24.1 ms, total: 178 ms
Wall time: 202 ms
Out[2]: (<workingctx 8ff14e46c9d8+>, set())
Reviewed By: DurhamG
Differential Revision: D26726476
fbshipit-source-id: e34218769c779c9a4ee64c654c75298b7c79f213
Summary: Now dirsync works with IMM rebase. Add a test for it.
Reviewed By: DurhamG
Differential Revision: D26726478
fbshipit-source-id: 6712538d7e903ddb0e3c3df44f7dde638276e99d
Summary: Now dirsync works with absorb. Add a test for it.
Reviewed By: DurhamG
Differential Revision: D26726477
fbshipit-source-id: 4505ad6c1e1fd03bfb2cf12b46bd07c98f2bcc2b
Summary:
Previously, dirsync wraps `repo.commit`, requires an on-disk working copy,
and dirstate to work properly. This diff updates dirsync to wrap
`repo.commitctx` instead, do commit edits purely in memory, then sync the
commit back to disk. It makes dirsync compatible with absorb and in-memory
rebase (and potentially other things like drawdag, if drawdag's context APIs
are improved).
To sync the changes made in-memory back to the filesystem, a dirstate callback
is added to write back mirrored files from commit to disk. This works for both
amend and absorb so the special wrapper about amend is dropped. It is
also optimal for absorb, because it only writes the mirrored files once for
the "final" commit, instead of writing the files for each commit in the stack.
Some `O(N^2)`s (N: len(status)) complexities were avoided:
- `applytomirrors` was called N times.
- `allchanges = set(status.modified + status.removed + status.added)` in
`applytomirrors` was O(N).
- `sourcepath in status.removed` in `applytomirrors` was O(N).
- `mirrorpath in status.removed` in `applytomirrors` was O(N).
Note there is still a suboptimal complexity of `getmirrors` called per changed
path, `O(N*M)` (N: len(status), M: len(dirsync_conig)). That will be addressed
in a later diff.
Reviewed By: DurhamG
Differential Revision: D26726479
fbshipit-source-id: 482c6c830ab65cc0d9cd569a51ec610a1dac49cc
Summary:
## Why this diff
we want hostname prefix to support targeting configs at clients in corp ("corp" means laptop, labs, and other machines that are not in "prod" datacenters), like FRL machines, that don't support our existing tier mechanism.
## Changes
* Extract hostname prefix in `dynamicconfig.rs` and add a getter function `hostname_prefix()` for it.
*A hostname prefix only consists of alphabetical letters and dashes, which is followed by one or more digits in the hostname. If no valid match, the prefix is set to the empty string.*
* Use `gen.hostname_prefix()` in the `evaluate()` fn inside `mod.rs` to check the generator's prefix against a list of given prefixes.
* Copy changes from `configerator/source/scm/hg/hgclientconf/hgclient.thrift` to `fbsource/fbcode/configerator/structs/scm/hg/hgclientconf/hgclient.thrift`.
* Rebuild in `eden/scm/`.
Reviewed By: DurhamG
Differential Revision: D26706686
fbshipit-source-id: 725506a1c1f0983e981b0b3f3993c7c14510b1db
Summary:
dynamicconfig has logic to avoid loading remote configs during tests,
by checking the TESTTMP variable. Unfortunately, the tests currently run system
hg with that environment set, which causes it to generate incorrect
configuration for the real repository (i.e. fbsource).
Let's get rid of all test specific environment variables when running the system
hg. There's a comment in the code saying this breaks some tests (from 2017
03a31be593db), but as far as I can see they still work.
Reviewed By: quark-zju
Differential Revision: D26758364
fbshipit-source-id: 945cbd36f7eccc98149772a42421cbc51b157c5b
Summary:
The new test case failed on Mac because it didn't want to copy over a
symlink or something. Didn't dig too deep because 'rm -rf' works around it.
Reviewed By: sfilipco
Differential Revision: D26758985
fbshipit-source-id: 22ad7e23813bd6bfe86b91535d46c21ee59dfcd1
Summary:
`nonfilelogfctx` means the `fctx` does not have a backing filelog, is in-memory.
Previously, one of the `fctx` is assumed to be backed by a concrete filelog,
it will crash if that is no satisfied.
Reviewed By: DurhamG
Differential Revision: D26731810
fbshipit-source-id: f758f43dc140dbf6cc9b6234681c4830482e767a
