Summary: IdSet is more compact. This changes the order a bit.
Reviewed By: sfilipco
Differential Revision: D27339279
fbshipit-source-id: e9b50a47beba081b892eccd7711dbd6ab5c3a886
Summary: This will be used by the next change.
Reviewed By: sfilipco
Differential Revision: D27406591
fbshipit-source-id: fcacc35a9ae8ed96cebb2af804d26d1e5e83ad9e
Summary:
Add a way to flush the overlay map to disk so we can avoid network fetches over
and over.
Reviewed By: sfilipco
Differential Revision: D27406592
fbshipit-source-id: 7086ad665119cc3a0834f533690325c7a2363442
Summary: It will be reused elsewhere.
Reviewed By: sfilipco
Differential Revision: D27406593
fbshipit-source-id: 296cf5f50830bb7285e0cb9c7c15a9b374689819
Summary:
I spent some time thinking about how to flush the "overlay_map" to disk.
It is a bit tricky because the on-disk IdMap might have changed in an
incompatible way. I tried a few ways to verify the on-disk IdMap remains
compatible and didn't find a way that looks good (either slow - calculating
universal_ids, or is not 100% correct in corner cases).
Now I come up with this "just track x~n" idea. It trades memory usage (~2x
overlay_map) for easy-to-verify correctness, and efficient overlay_map
flush.
Reviewed By: sfilipco
Differential Revision: D27406583
fbshipit-source-id: 0b7fb3186a9c15f376c1dc4afe7f0516c25d3dec
Summary: It is not obvious. So let's add more comments.
Reviewed By: sfilipco
Differential Revision: D27406584
fbshipit-source-id: 9ce1215efc1a6d4849180c6693616613c08f2a51
Summary:
A sparse dag does not have full IdMap. Its IdMap only contains "universally known" entries.
Add a basic test about cloning from a sparse clone data and resolve vertex <-> id mapping
on the fly.
Reviewed By: sfilipco
Differential Revision: D27352018
fbshipit-source-id: 4a3f5f50be52e91bf7b2021cdc858bcab9c99e80
Summary:
The `NameDag::flush` API will actually rebuild the graph using a "parent" function.
That is not necessary if we got clone data, and won't work well for a lazy graph
(since the parent function talks about vertex names and some names are missing).
Let's bypass the `flush` function and write data directly in `import_clone_data`.
Reviewed By: sfilipco
Differential Revision: D27352019
fbshipit-source-id: a79569d25d858447b8c5eb86902b8d39ae0429a3
Summary: This will be used in tests.
Reviewed By: sfilipco
Differential Revision: D27343882
fbshipit-source-id: 5a2d94a9f755eed0fc27e5a11093b55c810dc8da
Summary:
Implement logic to export the clone data. This allows us to construct a sparse/lazy
dag via export + import CloneData.
Reviewed By: sfilipco
Differential Revision: D27343885
fbshipit-source-id: 71dc0d31e36876a8b6a8c3d7f3498be3262ce297
Summary:
Clone data can only be imported to an empty Dag and universally known vertexes
should be present in the IdMap.
Reviewed By: sfilipco
Differential Revision: D27343888
fbshipit-source-id: ba150d6afdbe15f0902ec20ff150a70657e24c80
Summary: Collect "missing" items and only use one request to fetch them.
Reviewed By: sfilipco
Differential Revision: D27406588
fbshipit-source-id: a5cd091b39d90c1ad0e7c5d509673c4665232304
Summary:
This will be used by upcoming changes. Sparse/Lazy NameSet will override it
to reduce network round-trips.
Reviewed By: sfilipco
Differential Revision: D27406590
fbshipit-source-id: a44a73b4aec6e14d6e82d55285fe1cfc0fcfd482
Summary: This will be used by upcoming changes.
Reviewed By: sfilipco
Differential Revision: D27343884
fbshipit-source-id: 0938b1fb3d90b35f9d51c468cffca53e3f421bb8
Summary: The `mut` was unused. Remove it to make the interface more flexible.
Reviewed By: sfilipco
Differential Revision: D27406594
fbshipit-source-id: 1cfa4921015fc89b6c71ed4a97d9c351f56c7370
Summary:
Remove some TODOs. This serves as fallback paths where batch prefetch didn't happen.
I'd expect most use-cases will trigger IdStatic set's batch prefetch logic (to be
added).
I haven't decided what to do exactly with "contains". Fetching remotely there seems
to require some kind of negative cache (ex. in mutation records there might be nodes
not in the graph). But it _might_ be okay to say the "contains" is a local-only
operation, too. I leave it as-is and we'll see how the Python world uses "contains"
later.
Reviewed By: sfilipco
Differential Revision: D27339275
fbshipit-source-id: ba70b3c84a391a8e395c73ccd1d7e08f92b0cbd0
Summary:
Put everything together. I used "programming error" extensively to
provide more context if we have to investigate issues in the future.
Reviewed By: sfilipco
Differential Revision: D27339278
fbshipit-source-id: 574a2c048dc1d24dbe690f862fec3e5078cb067a
Summary: Provide more context about what invariants we expect. Not just show "vertex not found".
Reviewed By: sfilipco
Differential Revision: D27339273
fbshipit-source-id: 1c6c92537ff37666ff603783adfd8f9ea770fbaa
Summary:
Makes NameDag own the state (logic) about how to send remote requests.
So NameDag can send requests on its own.
Reviewed By: sfilipco
Differential Revision: D27339282
fbshipit-source-id: 3cb6327dfeaefae45d4e7b88a3535463a84b195b
Summary: This will make the overlay IdMap effective when query against the NameDag.
Reviewed By: sfilipco
Differential Revision: D27339276
fbshipit-source-id: 80712bf651beb6c7e9f23bd4233c6d916101696a
Summary:
When watchman is in use, removing tons of files very quickly leads to FSEvents
losing events, causing watchman to recrawl the entire repository. It's not
entirely clear today what the maximum number of threads to use is, let's make
it configurable.
Reviewed By: andll
Differential Revision: D27536577
fbshipit-source-id: 58f2bc453321fd4e7468d3324ee4df2b79b96d5d
Summary:
We already checked size and mtime, which should allow us to identify if
a file has changed since the last update, but we need to check hgid as well, to
make sure the previously-written content is supposed to be the same as the
about-to-be-written content
Reviewed By: andll
Differential Revision: D26955401
fbshipit-source-id: 859ad35b008e68d699601217f2a4398c6789913e
Summary:
Updates native checkout to store which files have already been written
in .hg/upgradeprogress. Then enables it to load that file and skip writing those
files if they're already on disk and their mtime and size match the previously
written values. In theory we could record and check file hashes as well, but
that'd likely slow things down quite a bit.
Future diffs will add:
- Recording and checking the hgid that was written before vs what is about to be
written. Just an hgid comparison, not a full hash computation.
- Some UX to inform the user when hg checkout can be continued, and possibly to
implement 'hg checkout --continue'.
Reviewed By: andll
Differential Revision: D26830249
fbshipit-source-id: 88a75080966dae5241550ed7eedbc057c65966dd
Summary: Vendor updated zstd crates. Started on this as a prerequisite for vendoring updated async-compression crate, however dependency resolution means this actually updates async-compression as well.
Reviewed By: farnz
Differential Revision: D27467760
fbshipit-source-id: 74ca9e4da9f336cf609cf06c62559c9ef913c9a2
Summary:
The extensions loading logic built up an _order list to track what order extensions should be loaded in. It also treated that list as the list of what has already been loaded, if we load extensions multiple times (like once at dispatch, then later for repo creation). Unfortunately some extensions, like tweakdefaults, modify the _order list, so when extensions uses len(_order) to decide which extensions are new, it sometimes gets the wrong results because tweakdefaults has inserted values at the beginning of _order which messes up the offset.
This causes some extension's uisetup and extsetup to be invoked twice. With dynamicconfig on Windows, I was seeing pushrebase load twice, which caused an error due to double registering bundle2 parts.
Extension loading is a mess, so this whole ordering concept really doesn't make sense, but for now let's fix it by not relying on the _order offset.
Reviewed By: quark-zju
Differential Revision: D27470828
fbshipit-source-id: e7ab8f87dfde22d82e5e080e8c01b884458b30c3
Summary:
Add a `set_global_config` function to `hg-http` that gets called prior to command execution. This function can be used to configure the global behavior of all HTTP requests by setting up a callback that modifies every `Request` prior to sending.
Right now, the use case for this is to support the `--insecure` flag, as can be seen in the code.
Reviewed By: quark-zju
Differential Revision: D27243638
fbshipit-source-id: 61a52c1f4b56fffd860c2a7e9c7b03e146b2240a
Summary: Add the `--insecure` flag to the list of global hg flags. This flag is already supported by Python, and adding it here will make it available to Rust code as well. This is used later in the stack.
Reviewed By: quark-zju
Differential Revision: D27243029
fbshipit-source-id: 150d42ee96e1e3194ff1be6a33d9b36887d86f2c
Summary:
The `focusedbranch` revset should only include commits that are related via
draft commits. If a commit is landed, its public successor shouldn't cause
focused smartlog to include descendants of the landed commit.
Reviewed By: quark-zju
Differential Revision: D27461850
fbshipit-source-id: c0eb4fbcd6cf1cd78a88e3f796b5a16257dfb190
Summary:
When running `sudo mkscratch path /home/markamendoza`, the folder `/data/users/markamendoza/scratch/homeZmarkamendoza` will be created, including all parents that did not already exist. All these new directories will be created with owner = root.
Anticipating this kind of call, `mkscratch` already goes in and manually modifies the owner of the leaf directory (e.g. `/data/users/markamendoza/scratch/homeZmarkamendoza`), **but will not do so for any of the parent folders it created**.
This is normally not a problem, as long as `/data/users/markamendoza/scratch/` already exists. If it doesn't then these directories are created with the wrong ownership, which causes problems if we (for example) call `mkscratch` again, without sudo.
This diff remedies this by calling the same `set_file_owner` function (that's already called on the leaf directory) on all parents that were created by `mkscratch`
Reviewed By: chadaustin
Differential Revision: D27378153
fbshipit-source-id: 26c40f4ca478cacf9117093c7b70cbedd679cea6
Summary:
Preserving that state causing some bugs.
Also it leads to accumulating lots of .eden-backing-repos/fbsource/.hg/store/commitcloudstate.user files.
It is cleaner to remove it.
Reviewed By: markbt
Differential Revision: D27461467
fbshipit-source-id: 21eebe799afcb919539ae059fc8b707abc74971c
Summary:
Support the `--history` flag (and other flags from `hg cloud sl`) on `hg cloud
ssl`. The only real difference between the two is the template.
Fetching the phabricator status for large number of commits can take a while,
so show a progress spinner while we do it.
Reviewed By: liubov-dmitrieva
Differential Revision: D27460144
fbshipit-source-id: c80830b85fd0766ad9c56afa9afea0c2d21f9b36
Summary:
Replace the implementation of `hg cloud sl --history` with one that uses
streampager. This allows the user to scroll around the rendered smartlog while
also switching from one version to the next.
The old (broken) history is available by setting `commitcloud.useoldhistorytui` to true.
Reviewed By: quark-zju
Differential Revision: D27268251
fbshipit-source-id: 77501e4b7f3da9506cd5a9cabb9cba0388743723
Summary:
Add bindings for `pysptui`. This allows using `streampager` as a TUI, using
streampager's controlled file mode to manage the display.
Reviewed By: quark-zju
Differential Revision: D27268252
fbshipit-source-id: d191a09c44ca4ed013647feb81e6f031d553b2f2
Summary: In a later diff, I plan to make this `pub` in order to parse HTTP versions from the user's config.
Reviewed By: quark-zju
Differential Revision: D27449576
fbshipit-source-id: 28a60080393eff73399c65b9e808647b39603719
Summary:
Production confidence team wants a simple tool to capture current state of the repo and get a commit hash in commitcloud
ephemeralcommit achieves that by making a hidden commit and pushing it to commitcloud
Main purpose of this is to use with ephemeral fbpkg, this produces relatively low volume of commits (comparing to total commit count).
This currently does not add untracked files, but removes missing files
Usage:
```
# note that when invoking from automatic tools need to specify -q
$ hg debugephemeralcommit -q
<hash of the commit>
```
Reviewed By: quark-zju
Differential Revision: D27339320
fbshipit-source-id: 07a4ea8ff80b80ce620fb609096db97f46d383dc
Summary: WSAEACCES is included in Windows only. Only check it if the os is windows.
Reviewed By: quark-zju
Differential Revision: D27434606
fbshipit-source-id: 25eb8036363b42629fbd010f7637a404dccff236
Summary:
`isinstance(i, int)` is problematic on Python 2 Windows:
In [1]: isinstance(72057594037927936,long)
Out[1]: True
In [2]: isinstance(72057594037927936,int)
Out[2]: False
Fix it by replacing `isinstance(_, int)` with a pycmpat function.
Reviewed By: DurhamG
Differential Revision: D27436107
fbshipit-source-id: 9d9d9f9359546a91a564d948718078a9aa594420
Summary: Integration test and macOS tests did not run at diff time.
Reviewed By: DurhamG
Differential Revision: D27436108
fbshipit-source-id: ab94ec88bad8de42025f539023ab426002b9bed5
Summary: Expand the IdConvert implementation so we can change it.
Reviewed By: sfilipco
Differential Revision: D27339280
fbshipit-source-id: eb55c63529c895502a25bb279bcba3c13737452a
Summary:
Add an overlay IdMap field for NameDag to store temporary remote IdMap results.
This diff just adds the field. It's not used yet.
Reviewed By: sfilipco
Differential Revision: D27339274
fbshipit-source-id: dbbde227f26de15d10c84f5d7c61ca8054577752
Summary:
In a future diff, AbstractNameDag wants an "overlay" IdMap to store temporary
remote IdMap results. The MemIdMap is suitable but has extra features (next
free id, version). Extract the core in-memory IdMap logic for the "overlay"
purpose.
Reviewed By: sfilipco
Differential Revision: D27339277
fbshipit-source-id: 4e73032b8bc6670264e3fa1dd5515ea3bc853d10
Summary:
The `Process::process` contains logic to resolve Id <-> Vertex using remote
service. The remote service is async so let's make `Process` async.
Reviewed By: sfilipco
Differential Revision: D27308798
fbshipit-source-id: 30c2c3eda124d542d0867d278ce56a7a174f33e0
Summary:
The config turns on fsync for all indexedlog writes. It can be useful in places
where we want reliability more than performance with unknown kernel issues.
Reviewed By: sfilipco
Differential Revision: D27347595
fbshipit-source-id: c0b31928684e8805a9e6441062f96b05ad311ea2
Summary:
Add a global flag, if turned on, ensure all atomic files, and indexes and
primary logs use fsync.
Also enhance fsync so it syncs the directory too.
Reviewed By: sfilipco
Differential Revision: D27347596
fbshipit-source-id: 831e27e494cc343a33ca675619c030ead8023210
Summary: test-lfs-placeholders.t fails on windows. The code isn't used on Windows so mark the test as no-windows.
Reviewed By: sfilipco
Differential Revision: D27433793
fbshipit-source-id: 4cbf70efae655ca318d776f6a2d6b79e83c78cbc
Summary:
Add a way to disable revnum resolution for non-automation (non-HGPLAIN)
usecases. Automation (ex. nuclide-core) still use revision numbers.
Some tests still use revnums. Put them in a list so this feature
does not break them.
Reviewed By: DurhamG
Differential Revision: D27144492
fbshipit-source-id: fba97fc90c7942e53914c29354938178b2637f44
Summary:
Manifest parent triggers an unimplemented tree history fetch path and is
generally prone to errors. See D9013996 (2b7e9e5e8b) and D9013995 (9e51fdef40).
Reviewed By: DurhamG
Differential Revision: D27411626
fbshipit-source-id: aee79f7928f0eb7fd39f68d12ec3ca33873f4e0b
Summary: Use Edenapi book request and response type in bookmarks edenapi endpoint. Serialize the response as cbor.
Reviewed By: kulshrax
Differential Revision: D27174122
fbshipit-source-id: 6bc7295c25bd355db4625da3c1f8c68349e7b0b7
Summary: Add edenapi types for the bookmarks endpoint. Now the endpoint can handle a request for a batch of bookmarks instead of a single bookmark. The request type still needs to be modified at some point to allow for bookmark prefix listing.
Reviewed By: kulshrax
Differential Revision: D27133284
fbshipit-source-id: c3960629cad76504e222f726a151eb3390850276
Summary: This fixes various tests on Windows. Many of these fixes were ported from upstream.
Reviewed By: markbt
Differential Revision: D27174617
fbshipit-source-id: b9f36ad0714793f2b76db32c1d840284b744a841
Summary:
The placeholder mode is meant to be used when talking to LFS server is not available in
given environment. It allows the user to work in degraded mode where
all of the LFS files are replaced with placeholders informing about their
original sizes and hashes.
Reviewed By: xavierd
Differential Revision: D27294603
fbshipit-source-id: 2bb8e2cb74ffccefcd90d618d6791ce5c45755d6
Summary:
Manual import from https://github.com/facebookexperimental/eden/pull/81 as the auto import mapped the .yml paths incorrectly
Updates eden/scm/Makefile to use python3 so we don't need to install multiple py versions
Adds hgext.convert.repo to setup3.py packages as mononoke tests showed it was missing
Updates github actions python versions
Reviewed By: quark-zju
Differential Revision: D27367568
fbshipit-source-id: 3817bdc1c48a8f7bfa8e29b5f7ec87d0eed579a9
Summary:
Like it says in the title. We don't use this anymore.
Context in D27268419
Reviewed By: markbt
Differential Revision: D27268635
fbshipit-source-id: 236adb5e68bc67612610d99f626344f4d592b5f9
Summary: Add a test target to the eden_scm getdeps manifest and underlying Makefile
Reviewed By: markbt
Differential Revision: D27336805
fbshipit-source-id: 07ec4be1ff03c6a384451ce138d88938dd4bf86e
Summary:
The `remotebookmarks` field in the local commit cloud state should always be one of:
* The empty set, if the previous sync was performed with remotebookmarks sync disabled; or
* The cloud workspace's remote bookmarks for that version.
Currently when processing remote bookmarks, we may store in the local state the
outcome of conflict resolution for the remote bookmarks. This is the wrong
thing to do, as it means we won't then upload those conflict resolutions as a
new cloud version, which means they may get lost and rolled back.
Change application of cloud remote bookmarks to store the cloud remote bookmarks
in the local state, even if we changed them through conflict resolution. This
means we will always upload the newly updated remote bookmarks to the server,
and things will stay more in sync.
Reviewed By: quark-zju
Differential Revision: D27291238
fbshipit-source-id: 8e6a0ab150da5907d32b8127aa0e6ccb17df4eea
Summary:
When connecting to a commit cloud workspace where there are no draft commits to
pull, no local bookmarks to sync, but the remote bookmarks in the local repo
are ahead of the ones in the commit cloud workspace, we fail to sync the remote
bookmarks to the server.
This results in the remote bookmark rewinding on the next sync.
Reviewed By: quark-zju
Differential Revision: D27291237
fbshipit-source-id: 8ba56542492fda26b9cecb6726ddd1b85ed5c180
Summary:
With the mix of external pager and progress suspension, the progress might
be enabled by accident:
# pager: disable forever
disable_progress(True)
# suspension
with progress.suspend()
...
# on __exit__, re-enables pager
Update the pager disabling logic be nested to avoid the potential issue.
Reviewed By: andll
Differential Revision: D27275016
fbshipit-source-id: 35ca7aef1890a981e6a1f0e5313b6a482ed43368
Summary:
Currently dropping progress bar panics if `__exit__` returns error
This happens, for example, when handling interrupts. Best course of actions just do not panic in this case
Reviewed By: sfilipco
Differential Revision: D27334897
fbshipit-source-id: c879fb14cfd4c16c0f9caede552129f8117defdc
Summary:
The progress total can be expensive to calculate for generatorset. Do not
calculate it. This will preserve laziness of certain sets (ex. generatorset
used by fastlog and average directory log).
Reviewed By: sfilipco
Differential Revision: D27327127
fbshipit-source-id: b0e3655e33b9e89ee2100941af18a769315f25bb
Summary:
Buffering the stream can provide suboptimal UX if the stream is slow.
Detect slow streams and avoid full buffering.
Reviewed By: sfilipco
Differential Revision: D27327128
fbshipit-source-id: a7b8037b7ba28fccc10661ffd15fd68f191d0048
Summary:
Refactor `scmstore::types` into separate `file` and `tree` modules and introduce a new `StoreTree` type to represent trees in the scmstore API.
Introduce a minimal `StoreTree` type. Importantly, for now this type does not provide any methods for deserializing the tree manifest and inspecting it's contents. This functionality won't be too hard to implement, though - it'll require some revisions to the `manifest-tree` crate and / or moving the `StoreTree` and `StoreFile` types to `revisionstore_types`.
Reviewed By: kulshrax
Differential Revision: D27310878
fbshipit-source-id: 712330fba87f33c49587fa895efea3601ce377af
Summary:
The revset is not optimized for the (to be migrated to segments) revlog backend.
Optimize it.
Reviewed By: jteosw
Differential Revision: D27317708
fbshipit-source-id: cec9d6aad0f6c30c69a931898f8e1cc7c904b3f8
Summary: Previously, accessing both repo.filelog and repo.manifestlog in a test debug command, under buck builds only, would cause a "memcache singleton leaked" error to be printed after the command completes (see https://www.internalfb.com/intern/qa/87181/runtime-warnings-about-memcacheconnectionmanagerim ). There are still some unanswered questions about this issue, as noted in the QA post, but this fixes the main issue at hand.
Reviewed By: sfilipco
Differential Revision: D27297498
fbshipit-source-id: e19665333bae9f91e1c3c6db370962a3aea2727d
Summary:
Rename "newstore" to "scmstore"
The three main options I'm considering are "edenstore", "scmstore", and "hgstore". They all describe the project sufficiently well, in my opinion. "edenstore" might be a stretch, as I have no reals plans for Mononoke to use it, while "hgstore" might be a bit limited, as integration with EdenFS is a core goal, and it'll be used by EdenFS to fetch remote data via EdenApi, not just Mercurial's local storage. I feel like "scmstore" rolls off the tongue the easiest, particularly vs. "hgstore" (both "H.G. Store" and "Mercurial Store"), and is a bit easier to type than "edenstore" (which has "ede" all with the same finger). I don't have a strong opinion on this matter, so If you'd like a different name I'm open to suggestions.
Speak now or forever hold your peace.
Reviewed By: andll
Differential Revision: D27180332
fbshipit-source-id: 19e6972ea0f6527e671792845dcfd339cf1ab767
Summary:
Introduce a new `StoreFile` type for the `revisionstore` crate. This is an enum of `File`, `LfsPointer`, and `RedactedFile`, which represent the different cases the `Entry` type's `content` might actually represent. The `File` variant also handles stripping the copy header, if present, and stores both the `copied_from`, raw unstripped `content`, and stripped `content`, though only the latter can be accessed through the public API right now. Ideally, we'll move copy information into the history API and never actually need to make it public here.
Conversions are provided from `Entry` and EdenApi's `FileEntry` type (which also supports redaction and LFS pointers, but as errors instead of first-class values).
Modify the output type used in the Python bindings to use this new `StoreFile` type.
Currently, the `LfsPointer` variant is unused. This will be used later when we add first-class LFS support.
Reviewed By: kulshrax
Differential Revision: D26862710
fbshipit-source-id: 8326921f3ee43bf2e253847d5735c61f5a50bfa6
Summary: Adds `ExtStoredPolicy` support to the EdenApi and IndexedLog ReadStore implementations. This flag controls how LfsPointers found during a file query are handled (either returned as a result, or treated as "not found").
Reviewed By: kulshrax
Differential Revision: D27171814
fbshipit-source-id: 14dda47f32184c3ee703fbc77106885ca4d3ea27
Summary:
Make the `RequestCreationEventListeners::new_request` event listener take an `&mut Request` instead of an `&mut RequestContext` as a parameter.
In the existing code (particularly in the `hg-http` crate), this event listener is used to configure the `RequestContext` for reporting progress. This diff just generalizes this idea, allowing the listener to modify the entire `Request`.
This is useful when we need to hijack request creation in `hg-http` to do Mercurial-specific configuration. The specific use case here is to disable TLS certificate checking when the global `--insecure` flag is set.
(Note that `http-client` itself is application-agnostic, so Mercurial specific configuration should not happen in this crate. This is why `hg-http` exists at all.)
Reviewed By: quark-zju
Differential Revision: D27242947
fbshipit-source-id: 019e19037642fe24acaa8c2917d446b91e7bcb26
Summary: Add `verify_tls_cert` and `verify_tls_host` settings to `http-client::Request` that are equivalent to [`CURLOPT_SSL_VERIFYPEER`](https://curl.se/libcurl/c/CURLOPT_SSL_VERIFYPEER.html) and [`CURLOPT_SSL_VERIFYHOST`](https://curl.se/libcurl/c/CURLOPT_SSL_VERIFYHOST.html). These will be used to allow skipping cert validation with the `--insecure` flag.
Reviewed By: quark-zju, sfilipco
Differential Revision: D27242946
fbshipit-source-id: cfa0fe800d0d132ca10ec0203bfd20b53c68b814
Summary:
The `Request` builder's methods currently take `self` by value, which was intended to make it easy to create new `Request`s in a fluent style without assignment. Unfortunately, it turns out that this complicates situations where we need to modify a `Request` in-place.
The ideal solution would be to change `Request`'s builder methods to take `&mut self` instead [1]. I tried doing this, but unfortunately there are too many other parts of the current design that rely on the existing behavior in ways that are difficult to change (particularly around the creation of streaming and async requests).
As a workaround, this diff simply adds matching `fn set_X(&mut self, ...) -> &mut Self` methods for each builder method on `Request`. The existing consuming methods have been rewritten in terms of those methods to prevent duplication of the actual method contents.
Given that all of the consuming builders now contain essentially the same body, it seems like we could reduce the verbosity here by using a macro. Unfortunately, I'm not sufficiently experienced with writing nontrivial macros to come up with something quickly, but I do think that it would be a good idea to eventually use a macro here.
---
[1]: In fact, it turns out that [this is considered a better practice](https://github.com/rust-lang/api-guidelines/discussions/81) when designing builders in Rust -- as long as the terminal method of the builder chain returns the built struct by value, it is still possible to create a new instance without assignment. This does mean, however, that we cannot easily move things from the builder to the final struct without using tricks like `Option::take` and `mem::swap`, since the signature of the terminal method would be `(&mut self) -> Self`).
Reviewed By: andll
Differential Revision: D27256048
fbshipit-source-id: 14f770a87abc839d358e5ba211a096226d3e0dc6
Summary:
Similar to D27064825 (7eea44ce4e). There are 2 `hg status` calls and D27064825 (7eea44ce4e) only fixed one of them.
Sample failure:
--- test-doctor.t
+++ test-doctor.t.err
@@ -226,11 +226,11 @@
$ hg status
M A2
A A0
- A X
R A
R A1
? B
? C
+ ? X
? Y
? Z
Reviewed By: kulshrax
Differential Revision: D27249712
fbshipit-source-id: 0e628959c88218d6340f2597953850d654b12a8c
Summary:
This is a follow-up to D27093942 (59b8287c85). But D27093942 (59b8287c85) forgot one `read_log` spot, making it
possible to lose data.
Reviewed By: andll
Differential Revision: D27265233
fbshipit-source-id: ab1e73cdcfd3cc9da2e19000ee5fd5761977dc4a
Summary:
Turns out D27093942 (59b8287c85) was not a complete fix. It misses a `read_log`. Add a
test showing the problem.
Reviewed By: andll
Differential Revision: D27265232
fbshipit-source-id: 103e543abacbb2cbaf10aa3fe3d9693922d9daad
Summary:
There are a few abstractions in this that make it a little hard to
have different behavior between the download & upload paths.
This makes it hard to have different behavior for the two. It's a bit of a
problem right now in the sense that we end up doing things like sending a
Content-Length on a GET, but the reason I'm changing it is because I want to
chunk downloads and that requires having different logic in the upload &
download paths.
As part of doing this, I also moved a bunch of parameters away from
HttpLfsRemote and into HttpOptions, which makes the function signatures a
little more manageable.
Reviewed By: quark-zju
Differential Revision: D27191593
fbshipit-source-id: c332229bb3c5a4c1eaedb54dc12c3ddc19205050
Summary:
Git client was updated and it started outputting a hint that breaks our tests. It has no meaning in tests so just quiet it.
```
➜ fbcode git init
hint: Using 'master' as the name for the initial branch. This default branch name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint: git config --global init.defaultBranch <name>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint: git branch -m <name>
Initialized empty Git repository in /data/users/mzr/fbsource/fbcode/.git/
```
Reviewed By: StanislavGlebik
Differential Revision: D27232853
fbshipit-source-id: 683ebebb36049adb758e7c26f843f12159a45301
Summary:
eden/scm/lib: default cpython_ext to python3
```
CI internally, try a PR on github once its landed.
Reviewed By: quark-zju
Differential Revision: D27237636
fbshipit-source-id: 1768f778d75b5d6c62dfd5641f911604a37d3163
Summary: Fix malformed module-level doc comment and rearrange import groups (based on the de facto Rust style conventions at FB).
Reviewed By: quark-zju
Differential Revision: D27243739
fbshipit-source-id: 21614d16e5fbfecd793939325ef52819db9a4cb8
Summary:
Hide private functions that might not have a stable interface guarantee in
`help`. For example, `help revset`:
Before:
Predicates
==========
The following predicates are supported:
"_all()"
All commits regardless of visibility
"_destrestack(SRC)"
restack destination for given single source
revision
"_localbranch"
"_localbranch(changectx)" localbranch commits
After:
Predicates
==========
The following predicates are supported:
"adds(pattern)"
Changesets that add a file matching pattern.
The pattern without explicit kind like "glob:" is expected to be
relative to the current directory and match against a file or a
directory.
Reviewed By: DurhamG
Differential Revision: D27130002
fbshipit-source-id: ee098489223c4033edeca2e5b6acab9475e63eb5
Summary:
Remove use of `#[async_trait]` in the new storage API, and eliminate the outer Future on the `fetch_stream` and `write_stream` methods, which was not used. The methods are now normal trait methods, which accept and return a stream.
It's possible we'll want to make these methods `async` again in the future, but until this this is more ergonomic, faster (one less layer of indirection), and avoids some of the type system limitations of `#[async_trait]`.
Reviewed By: andll
Differential Revision: D26695517
fbshipit-source-id: 2db60a3f37d594b0b9d1e1a2708532ef0ddaf585
Summary:
Introduce `FilterMapStore` combinator to support cases like LFS, where values of the same type may or may not be supported by a given store implementation.
Use `FilterMapStore` in Python bindings to prevent LFS files from being accidentally written to the non-LFS indexedlog.
With this change, the new storage API should be safe to use without corrupting local storage.
Reviewed By: kulshrax
Differential Revision: D26651254
fbshipit-source-id: 629cb43d85f43117a32b577777e13ff8fb801d57
Summary:
Introduce `HashMapStore`, a HashMap-based, generic, in-memory `ReadStore` / `WriteStore` implementation for testing purposes (and perhaps other uses in the future).
Introduce a minimal `KeyedValue` trait so that `HashMapStore` can determine the key to be associated with a written value in a generic way.
Reviewed By: kulshrax
Differential Revision: D26859235
fbshipit-source-id: 66032f072148796bde7a3a176fb2bb6707b95287
Summary:
Introduce `WriteError` type (similar to `FetchError` for reads) to support strongly-typed write errors. Eventually we'll probably want this type to carry the value that we tried to write (to allow write fallbacks, retries, etc) and perhaps add more enum variants (rejects, unavailable, etc).
Introduce `ReadWriteStore` trait for stores that support both reading and writing. This trait is automatically implemented for types which implement `ReadStore` and `WriteStore` with the same key and value types. This trait is intended to be used via the `BoxedRWStore` trait object. This type will be used in the Python bindings when `FallbackCache` is extended to implement `WriteStore` (in a future change).
Reviewed By: kulshrax
Differential Revision: D26646393
fbshipit-source-id: 96058cf1e826fdb6076a4162389829b3fe053686
Summary:
Introduce newfilestore class in pyrevisionstore, which constructs a newfilestore (BoxedReadStore for files) and a corresponding `ContentStore` which share the underlying IndexedLog object and EdenApi client.
Modify remotefilelog to construct ContentStore via this new class.
Currently, no methods are provided for the newfilestore - it is meant to be passed back into Rust code, where you may call it's Rust methods as shown in the `test_newstore` method (which will be removed in the future).
Currently the `util` module is made public for access from pyrevisionstore. In the future, this will be replaced in favor of a `NewFileStoreBuilder` which handles these concerns internally.
Reviewed By: DurhamG
Differential Revision: D26526331
fbshipit-source-id: c0f439fbee4c303db4a82171c866a3f3a5fc2324
Summary:
Split `FallbackStore` (which supports writing fallback fetches) into `FallbackCache` (which behaves the same) and `Fallback` (which doesn't support writing fallback fetches). This eliminates the `From<>` bound on `Fallback` which is nonsensical in some cases where we don't want writing.
Replace `write_store` and `write` fields with a single `Option<>` `write_store` in `FallbackCache`, which cleans up the code a bit.
Separate the "fallback value type", "preferred value type", "write value type", and "output value type" separately control the output value type independent of the preferred store.
Reviewed By: kulshrax
Differential Revision: D26526149
fbshipit-source-id: aa9f25f5efb8a9ddab03a7d86a7a007f24d156ce
Summary:
Add an `edenapi.logdir` config option, which, when set, will cause the EdenAPI client to write a JSON version of every request it sends to the specified directory. This is intended for use when reproducing user issues (so that the developer can inspect and replay the requests that were sent).
The JSON request files can be directly given to the `edenapi_cli` or converted to CBOR using the `make_req` tool for manual testing with `curl`.
The approach right now is a bit simplistic, in that we just write a JSON file whenever the EdenAPI client makes a request. I'm open to suggestions on how to improve this. (For example, if there were a way for us to always have a record of the last N requests, that would be helpful for debugging user issues.)
Reviewed By: DurhamG
Differential Revision: D27145093
fbshipit-source-id: 3834c2052b0c5efa05d1d209962953b29f545a3f
Summary: noticed these in passing while working on previous diff
Reviewed By: mitrandir77
Differential Revision: D27227682
fbshipit-source-id: e7858c81951b780722b0836ecf6ee72aeb1ffa09
Summary:
The latest git prints extra hints:
$ git init repo
+ hint: Using 'master' as the name for the initial branch. This default branch name
+ hint: is subject to change. To configure the initial branch name to use in all
+ hint: of your new repositories, which will suppress this warning, call:
+ hint:
+ hint: git config --global init.defaultBranch <name>
+ hint:
+ hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
+ hint: 'development'. The just-created branch can be renamed via this command:
+ hint:
+ hint: git branch -m <name>
Initialized empty Git repository in $TESTTMP/repo/.git/
Silent it to make the test pass.
Reviewed By: akushner
Differential Revision: D27235547
fbshipit-source-id: 6f7c8da3ac1e01ee9f57730e1586fa2053f9ca98
Summary:
a workspace could be renamed from a different machine
educate users that they need to switch to a valid workspace
Reviewed By: markbt
Differential Revision: D27155544
fbshipit-source-id: eed066f2f3e6ebf99732499fdb355f8aebb4c1df
Summary:
this could happen if it has been removed from a different machine
In this case, we should educate the users about the '--force' option
Reviewed By: markbt
Differential Revision: D27155423
fbshipit-source-id: 41cc3ac769dfd4145031fef687e8069d0ef8f4c9
Summary:
provide better ux for switching workspace if the current has been renamed from another machine
sometimes users rename a workspace but it's unclear for them how to switch other machines to the new one
we should educate them about '--force' option
Reviewed By: markbt
Differential Revision: D27117194
fbshipit-source-id: faef1cf9ce64f054f715ef3683a133d3088ddc72
Summary:
We've been seeing flaky test output due to python2 and python3 stdout being different
Bring getdeps builds unambiguously onto python3.
Reviewed By: mitrandir77
Differential Revision: D27190200
fbshipit-source-id: e53327fc3293a0ccdf88d8a199b66eddb4b9b8e4
Summary: There were a few remaining python2 parts to remove and the error case from hgcommand.run() had wrong encoding
Reviewed By: mitrandir77
Differential Revision: D27194046
fbshipit-source-id: 8c154204991e5a587f70ae4b18c73c4f005880ab
Summary:
This is unused, and the Thrift file mentions that it should be fine to remove
in July 2020. It's now March 2021, time to kill it.
Reviewed By: chadaustin
Differential Revision: D26852134
fbshipit-source-id: 2872185edd834f889b78802210071d16b881e14c
Summary:
See the previous diff for context. Disable the Rust progress for external
pager.
Reviewed By: kulshrax
Differential Revision: D27149241
fbshipit-source-id: 4260a8be55bbfa648d8910f021195e9d11bdab73
Summary:
When testing "disable_progress" with chg (next diff) I found it was not
effective because there are 2 separate IO structs. The one we disable
from Python is different from the one the Rust progress thread uses.
I traced it down here. Since the Python IOs are just wrappers of
Rust IOs in the chg use-case. There is no need to recreate an IO
struct.
The "creating IO" struct is still useful, for things like "-t.py" testing where
the output needs to be captured into different Python variables per different
commands.
Reviewed By: DurhamG
Differential Revision: D27149243
fbshipit-source-id: 6e27adcc9f48b21fc24fba120be8c4a8fef1f909
Summary:
In some cases (ex. using an external pager). The IO states are changed outside
the IO struct's control. Ideally we should implement the external pager logic
on IO too but for now let's just add an API so the Python external pager logic
can disable progress output after starting an external pager.
Reviewed By: kulshrax
Differential Revision: D27149242
fbshipit-source-id: ff51fc153d3cc211cfa8ef697923d36f7c0f0d9b
Summary:
Detecting prod on Windows wasn't working because we used a posix path.
Let's add the Windows equivalent.
Also moves us to use the new hostcaps crate.
Reviewed By: chadaustin
Differential Revision: D27126497
fbshipit-source-id: 4035012fb7701378fb6e2e902c0efcd54ef42ea9
Summary:
We've been seeing issues where repositories end up with incorrect
dynamic configuration since there's a window of time after they're cloned where
they don't have %include /etc/mercurial/.../repo.rc and therefore generate an
incorrect dynamicconfig which gets used for 15 minutes until we regen the
dynamicconfig.
Let's change hg clone to write the %include as part of the initial hgrc, so we
remove that window of time and the repo will always be correctly configured.
Reviewed By: quark-zju
Differential Revision: D27093772
fbshipit-source-id: a9ca0ec54e06549546d532d1c49a80d49981decf
Summary:
I'd like to add support for event handlers in the Rust ServiceRouter client (I
need this in order to inject CATs in calls made by the SMC client). To do so, I
need to be able to instantiate a `ContextStack`, and to do so, I need a static
c-string representing the service name & function name, which is what this diff
does.
Note that we actually do the same thing for Rust servers already.
#forcetdhashing
Reviewed By: farnz
Differential Revision: D27088187
fbshipit-source-id: be2ad541d5123b31f0dab73da16b35dbfd308d6f
Summary:
In regular xcode this was warning and being ignores. Not the working is handled as an error.
This diff is only a workaround so we wont get those errors .
```
eden/scm/edenscm/mercurial/cext/osutil.c:745:49: error: passing 'const char *' to parameter of type 'char *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
ret = _listdir_batch(path, pathlen, keepstat, skip, &fallback);
^~~~
eden/scm/edenscm/mercurial/cext/osutil.c:586:11: note: passing argument to parameter 'skip' here
char* skip,
```
Reviewed By: mzlee
Differential Revision: D27136440
fbshipit-source-id: 00d61fd00e3ed8e23643ea69b5a82dbeb5e742ce
Summary:
With `sl -r OBSOLETED` the intention is see the obsoleted stack instead of just
a single commit. So filter the "::heads" with "- public()", not "& draft()".
The goal is to deprecate `--hidden`. See the linked post for more context.
Reviewed By: DurhamG
Differential Revision: D27093425
fbshipit-source-id: 76e9650a809c1d94da2341e2aca31d349487610d
Summary:
This creates .hg directories when there is no repository at all, which
breaks jf submit in git repos. D26801059 is the real fix, but it has some other
complications. Let's drop the creation here, since it really isn't necessary.
Reviewed By: quark-zju
Differential Revision: D27134087
fbshipit-source-id: d15048b2d1022d38393b62cc02ebf022e617ed4f
Summary:
When using `log -r REVS` with filtering flags like `-u`, `-d`, preserve the
prefetch information by using the `revs(subset=subset)` API.
Reviewed By: sfilipco
Differential Revision: D27119174
fbshipit-source-id: 8483d7113cfc819c6053d1429221588c3a917c12
Summary:
This allows specifying subsets. So we can rewrite:
revs & repo.revs(expr)
to:
repo.revs(expr, subset=revs)
The latter will apply prefetch tweaks on subset when evaluating the revset
expr, while the former will lose prefetch information.
There might be a way to make `revs & repo.revs(expr)` do the right thing
for pre-fetching, too. But that could be more complicated w.r.t `&` fast
paths, over fetching (?), etc. For now I just took the fix that looks more
obvious to me.
Reviewed By: sfilipco
Differential Revision: D27119175
fbshipit-source-id: 2629d21594cf97d7c0f63cf085a2c427d8782e58
Summary:
The filteredset can often be expensive filtering commits like `hg log -u foo`,
`hg log -d '2010-1-1'`. Add a progress bar to show what's going on.
Reviewed By: sfilipco
Differential Revision: D27119176
fbshipit-source-id: 458fbf331978b26e78e6a85fb194ae8b12b949d6
Summary:
`CommitHashToLocationRequestBatch` and `CommitRevlogDataRequest` implemented `FromJson` but not `ToJson`. The latter is required so that the EdenAPI client can log JSON representations of all request types.
In the process of adding tests for those two types, I discovered a bug in `CommitLocationToHashRequestBatch`'s `ToJson` implementation which prevented it from passing JSON roundtrip tests (which I added because this type didn't have test coverage here). The bug is now fixed and the roundtrip test passes.
Reviewed By: krallin
Differential Revision: D27105414
fbshipit-source-id: d2e23e21f996ac8062bca948ed9abe3779e4669d
Summary: Use a macro to define quickcheck tests that perform roundtrip conversions for EdenAPI types that implement `ToJson` and `FromJson`. This makes it easier to add additional roundtrip tests for new types.
Reviewed By: krallin
Differential Revision: D27105416
fbshipit-source-id: c6059f9527d57b88cd6e3d1647fa89d8f826b1e3
Summary:
editmerge did not follow the same editor fallback described in
https://www.mercurial-scm.org/wiki/HGEDITOR and `hg help
environment`. Make the fallback behavior (especially to `vi` if none
are set) consistent by defining HGEDITOR before invoking external
merge scripts.
Reviewed By: farnz
Differential Revision: D27104830
fbshipit-source-id: 0ca657578f010a682afb84649f2f18ff46046864
Summary:
Rework the progress. Always move the cursor to the top-left corner of the
progress output. So the clear progress instruction is just to erase till
the end of the screen. There is no need to track the height of the progress.
Update flush logic so we only do flush when crossing the progress/non-progress
boundary: When we write progress (to stderr), flush stdout, write progress,
then flush stderr.
Also, disable progress unconditionally if the current output line is incomplete.
Reviewed By: sfilipco
Differential Revision: D27109228
fbshipit-source-id: 717345e9c7eaeebeb378ce090f7b2f60957fd150
Summary: This makes write_err() consistent with error().write().
Reviewed By: sfilipco
Differential Revision: D27109227
fbshipit-source-id: 4e7ea1fe464c17548c34e5f9bf78085868a20256
Summary:
See the previous diff. This avoids complex logic in the signal handler so we
don't need to think about whether the complex logic is reentrant or not.
Reviewed By: DurhamG
Differential Revision: D27111183
fbshipit-source-id: 110ef5699d5fcd007f8399e90443bb406e2b173c
Summary: The zz could match temporary file names on Windows. Let's add the _ to make it more unlikely to match temp files.
Reviewed By: quark-zju
Differential Revision: D27100451
fbshipit-source-id: 5646bb2ad1e52b1f49c29729d424111601468c69
Summary:
Now that EdenFS and Watchman are compatible with hg shelve and other
rapid commit changes, this warning is no longer necessary.
This backs out D25337932 (c1659751c9).
Reviewed By: quark-zju
Differential Revision: D27095024
fbshipit-source-id: 31af1d2dafaa0f340a4ace10a16f9357ed84dbf0
Summary: This line just collects a vector into a vector. Probably a remnant of a refactor. Delete it.
Reviewed By: quark-zju
Differential Revision: D27091643
fbshipit-source-id: fb611aabea375b8495476401b2d9cdf7ba12fde1
Summary:
These appear to have been made effectively dead by cleanup in D25313325 (23daa7f90f).
This is part of unblocking the hashed buck-out rollout effort
(https://fb.prod.workplace.com/groups/fbcode.fyi/permalink/3694589863910121/),
as `get_build_rule_output_path()` relies on hard-coded buck-out paths.
Reviewed By: mzlee
Differential Revision: D27072131
fbshipit-source-id: 4fccee06a73c4afbf89cb737b25e1713a1afc55a
Summary: This makes the new software respects writes by older software.
Differential Revision: D27093942
fbshipit-source-id: 097b57c61b5ee1f0264babb88737306113fe356a
Summary:
`hg stauts` can be "indeterministic" because of the last second mtime fix
special rule (see pytreestate/src/lib.rs:invalidatemtime).
The test sometimes fails like:
test-sparse-fetch-t.py:140: [] != ['x', 'x/x']
Update it to support both `[]` and `['x', 'x/x']` case.
Reviewed By: sfilipco
Differential Revision: D27071225
fbshipit-source-id: c413906897b408c1e85912852afed1717a87ffc9
Summary:
The error was triggered but it's unclear what's wrong. Make the error
more detailed.
Reviewed By: xavierd
Differential Revision: D27058212
fbshipit-source-id: 3f6220e2d100d9118c05a8b4c75c5ba19c9181db
Summary: This will be used by `doctor` command.
Reviewed By: sfilipco
Differential Revision: D27053349
fbshipit-source-id: bc33e25997f30107f919a090ff68693bfdd7199d
Summary:
By implementing DefaultOpenOptions, indexedlog provides `repair()` for free.
Re-export the `Repair` trait so other crates can use `repair()` without
importing indexedlog.
Reviewed By: sfilipco
Differential Revision: D27053352
fbshipit-source-id: 8fa952f0e51e007b9d348bc12699ef1d65000c6b
Summary:
With the new log for MultiMeta. It's now possible to repair a MultiLog by:
- Repair all Logs
- Scanning through the MultiMeta Log and find a valid MultiMeta.
- Set the current MultiMeta to the picked MultiMeta.
Reviewed By: sfilipco
Differential Revision: D27053346
fbshipit-source-id: d60596fb00323b3bcadd5ade2e34cad29a37d64a
Summary:
We recently saw a few reports about "multimeta" being 0-sized. MultiLog cannot
be repaired like other logs because the logs (ex. IdDag and IdMap) have to be
in sync. To implement Repair for MultiLog, let's track MultiMeta in a Log so
we can check its previous entries and fix the multimeta.
Reviewed By: sfilipco
Differential Revision: D27053347
fbshipit-source-id: af99b13d658ee62bfe63973ab9d37338d14a7d4a
Summary:
The test failed sometimes on Linux:
--- test-doctor.t
+++ test-doctor.t.err
@@ -204,11 +204,11 @@
M A2
A A0
A
- A X
R A
R A1
? B
? C
+ ? X
? Y
? Z
The treestate fix appears to rollback to even a previous version, which is also
a valid fix. Let's accept that state too.
Reviewed By: DurhamG
Differential Revision: D27064825
fbshipit-source-id: 6aab04e66ad14ad651f93805c9652c7423178665
Summary:
The test failed sometimes on OSX:
--- test-fb-hgext-fastlog.t
+++ test-fb-hgext-fastlog.t.err
@@ -34,6 +34,7 @@
$ hg log dir -T '{desc}\n'
b
a
+ Exception in thread Thread-3 (most likely raised during interpreter shutdown): (no-eol)
$ hg log dir -T '{desc}\n' --all
b
a2
The threading usage in fastlog does seem kind of risky (especially with async
Rust involved). Race condition in Py_Finalize is not at all fun. Let's just
make the test more robust for now. In the future we probably want to avoid
threading in fastlog.
Reviewed By: DurhamG
Differential Revision: D27064618
fbshipit-source-id: a6c2ee5eda0fbd5120c8b5e5cfcc7af0f158f9b9
Summary:
The test is failing:
--- test-fb-hgext-remotefilelog-repack-remove-old.t
+++ test-fb-hgext-remotefilelog-repack-remove-old.t.err
@@ -63,7 +63,7 @@
-r--r--r-- 80 *.datapack (glob)
-r--r--r-- 80 *.datapack (glob)
-r--r--r-- 80 *.datapack (glob)
- -r--r--r-- 144 *.datapack (glob)
+ -r--r--r-- 80 ef52660a201e447b43868610b08c72e22067b8b2.datapack
We are migrating away from repack so I just made the test pass without
investigating what's going on exactly.
Reviewed By: sfilipco
Differential Revision: D27064249
fbshipit-source-id: 6bcd583b6ecbe0b373d9fec2b23269b0da6a27f3
Summary: This makes it easier to spot problematic segments.
Differential Revision: D27025039
fbshipit-source-id: 44ae9eaf03ca54751b64c0cf977b78737eaa58f0
Summary: The Rust commit graph does not hardcode nullid. This avoids crashes in some cases.
Differential Revision: D27022659
fbshipit-source-id: 0f61ffd9da89de7a477470384c6015d9edfaaaa0
Summary:
We saw the `unwrap()` panic at `iddag.rs:453`:
let (new_idx, low, high, parent_count, has_root) = candidate.unwrap();
Reading the code, it seems it can only happen if one of `parents` is `high` in a segment.
Parents in a segment should all be < low. Add some validations for that.
Reviewed By: sfilipco
Differential Revision: D27021394
fbshipit-source-id: 2c51713dfb8f07f2921229d8866f7e8a0bd9490f
Summary:
For example, `hg log > a.txt`, writing to `a.txt` does not need to clear the
progress bars.
Reviewed By: andll
Differential Revision: D26886281
fbshipit-source-id: 392c50e62a854e03ea0c400a1dac8bfb900815a2
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
