Summary:
This makes existing ui.debug appear in tracing debug output with correct
callsite information. They can then be filtered by the `EDENSCM_LOG`. For
example:
$ EDENSCM_LOG=edenscm=debug lhg dbsh
In [1]: ui.debug('foo')
Feb 19 20:03:31.795 DEBUG edenscm.hgext.debugshell: foo
Reviewed By: sfilipco
Differential Revision: D26582807
fbshipit-source-id: b3d97d43d8a31c7d42e3b5c86a05142206e2c9f7
Summary:
It's silly to use `eden prefetch --no-prefetch` to efficiently glob
for filenames. Introduce an `eden glob` command which resolves a glob
relative to the current working directory.
Reviewed By: genevievehelsel
Differential Revision: D25450358
fbshipit-source-id: 45d6dc870d21510e51d5662c75e80385886899fc
Summary:
I want to use EdenError from some code outside of service/, so move
EdenError into utils.
Reviewed By: genevievehelsel
Differential Revision: D25447438
fbshipit-source-id: 2d1ddfa379238369679e84708518a9ba106f76b9
Summary:
We shouldn't delete from a dictionary while iterating over it, instead we should iterate over a copy and then delete from the original.
`.keys()` returns a view of the dict, while wrapping it in `list` makes a deep copy.
Reviewed By: StanislavGlebik
Differential Revision: D26618782
fbshipit-source-id: 234503aab0a0a2151ae0818282651b547f414016
Summary:
The future has a "map" clause that takes GIL too. If they run in different
threads it could deadlock. For example, the following code might hang
forever:
In [1]: s,f=api.commitdata('fbsource',list(repo.nodes('master')))
In [2]: f.wait()
Reviewed By: sfilipco
Differential Revision: D26582806
fbshipit-source-id: e3259850c68b8d48a7a69ed9d47ef75f26179382
Summary:
Previously, one has to set both EDENSCM_LOG=trace and EDENSCM_TRACE_LEVEL=trace
to enable all logging. That is because the filtering is global - one subscriber
(or layer) filtering out a span or event, then the span or event is gone
forever.
For now, let's just set the TracingCollector Subscriber's filter level
(EDENSCM_TRACE_LEVEL) to TRACE so it solely depends on the EnvFilter
(EDENSCM_LOG) if EDENSCM_LOG is set. That's more friendly.
See `impl<L: Layer<S>, S: Subscriber> Subscriber for Layered<L, S>`:
fn enabled(&self, metadata: &Metadata<'_>) -> bool {
if self.layer.enabled(metadata, self.ctx()) {
// if the outer layer enables the callsite metadata, ask the subscriber.
self.inner.enabled(metadata)
} else {
// otherwise, the callsite is disabled by the layer
false
}
}
See also: https://github.com/tokio-rs/tracing/issues/302
Reviewed By: sfilipco
Differential Revision: D26518017
fbshipit-source-id: 9016b940621fc9a883e6ca3f00eaaeccc051ae74
Summary:
Now we use tracing_subscriber for equivalent features (by setting EDENSCM_LOG).
It's no longer necessary to forward to log eco-system.
Reviewed By: sfilipco
Differential Revision: D26518018
fbshipit-source-id: 7cc080faa734ca40eed1ce250df3135ca2626c1f
Summary: Now IO has internal locking, `mut` is no longer needed.
Reviewed By: sfilipco
Differential Revision: D26518025
fbshipit-source-id: d71e213f6fed24fdefb4c730d576f6cf2fb09d82
Summary:
Cloning IO would make it harder to run the clean-up logic in Drop (ex. flush,
stop the pager). Forbid it.
The weak reference output and error streams can still be cloned. They sastify
the main "clone" use-cases.
Reviewed By: sfilipco
Differential Revision: D26538451
fbshipit-source-id: 6cc59214ec5fe1340cb27c7ee1a09658bb83190a
Summary:
Similar to D26518021 (3aba8d89b0), provide a way to obtain the "output" stream
that implements `std::io::Write`.
The "output" stream is then used to replace the `std::io::Write`
implementation on the `IO` itself.
This has 2 benefits:
- Removes the `&mut` methods on `IO`. So all `&mut IO` can be replaced by `&IO` without exceptions.
- Make it possible to drop `Clone` on `IO` (strong ref is not clonable, but weak ref can). So we can control the lifetime of the streams more predicatably.
Reviewed By: sfilipco
Differential Revision: D26538452
fbshipit-source-id: b00c65ae0ef5ef4a609104111706365028f47ef7
Summary:
Use the global IO state instead of keeping a separate IO state.
This makes the Python pager logic able to affect the tracing logger's error
output. For example, the following command will write the tracing logs to
the streampager's stderr channel as expected:
EDENSCM_LOG=trace lhg log -r '.~1000::.' --config pager.pager=internal:streampager
Traditional pager also works:
EDENSCM_LOG=trace lhg log -r '.~1000::.' --config pager.pager=less
Reviewed By: sfilipco
Differential Revision: D26518024
fbshipit-source-id: c7020b7467f9392af8c2a58d064339d05bce35ce
Summary:
This makes the IOError stream used by tracing loggers use weak reference
so the main IO can still be dropped without being affected by potentially
lingering IOError values.
Reviewed By: sfilipco
Differential Revision: D26518022
fbshipit-source-id: df4c847a7a59fff39b7832190a8723c78ffae9ad
Summary:
Set the global IO reference to the IO created by hgmain. This allows
other crates like `pypager` to use the `IO` without cloning or passing
the reference across layers (Rust references do not actually work for
across the Python boundary).
Reviewed By: sfilipco
Differential Revision: D26518027
fbshipit-source-id: 6144b06035d0ef9384cc1a37245c306071e35a9d
Summary:
This makes it easier to figure out the "main" IO, similar to APIs like
`std::io::stdout`, without passing the IO around. It will be used by
the `pypager` module.
The global reference is a weak reference so it won't affect IO drop
behavior.
Reviewed By: sfilipco
Differential Revision: D26518015
fbshipit-source-id: ab75ec31cbb8f156b72c94a6fe5b2de6fe9e0bff
Summary: This will be used by pypager.
Reviewed By: sfilipco
Differential Revision: D26518026
fbshipit-source-id: ac8290501ea572cc5ce2067a52d62f4933cbe87b
Summary:
I encountered the error but it's unclear what happened. Print type_name to
clarify.
Now I get:
not implemented: converting non-stdio Write (alloc::vec::Vec<u8>) from Rust to Python is not implemented
This turns out to be an error in "clidispatch: make IO clonable" - The `Drop`
should be implemented on `Inner`, instead of `IO`. The fix has been folded
into that commit.
Reviewed By: sfilipco
Differential Revision: D26518016
fbshipit-source-id: ddb5f828c59cbffa9767694558113167bc96db4b
Summary:
The `wait_for_bookmark_update` function only waits for `mononoke_scs_server` to
update to the new bookmark value. `mononoke` might still be refreshing the
warm bookmark cache at this point, and might not have the value for `newkilo`
yet. Flush its bookmarks cache to ensure we get an up-to-date view.
Differential Revision: D26609089
fbshipit-source-id: c7c063e4eb96303d4fbd597c4153335a3c9d4429
Summary:
As useful as `eden strace` can be, it's hard to correlate inode
numbers to their filenames via the mkdir/create/lookup request that
returned the inode. Add logging for result codes.
Reviewed By: kmancini
Differential Revision: D26287958
fbshipit-source-id: dae4b56513831185b038546f238938b0d21a6bad
Summary: Done some reordering of fields in Cargo.toml, added test and doctest = false, name of the target that generated the Cargo.toml file and sorted the cratemap.
Reviewed By: ahornby
Differential Revision: D26581275
fbshipit-source-id: 4c363369438c72d43d8ccf4799f103ff092457cc
Summary:
The world has moved on utf-8 as the default encoding for files and data, but
EdenFS still accepts non utf-8 filenames to be written to it. In fact, most of
the time when a non utf-8 file is written to the working copy, and even though
EdenFS handles it properly, Mercurial ends up freaking out and crash. In all of
these cases, non-utf8 files were not intentional, and thus refusing to create
them wouldn't be a loss of functionality.
Note that this diff makes the asumption that Mercurial's manifest only accept
utf8 path, and thus we only have to protect against files being created in the
working copy that aren't utf8.
The unfortunate part of this diff is that it makes importing trees a bit more
expensive as testing that a path is utf8 valid is not free.
Reviewed By: chadaustin
Differential Revision: D25442975
fbshipit-source-id: 89341a004272736a61639751da43c2e9c673d5b3
Summary:
Simple test that can give us an intuition for how the ConcurrentMemIdMap should
perform.
Reviewed By: krallin
Differential Revision: D26601378
fbshipit-source-id: ae8f2ada6fc08eef806f3ece72a6c1c2f011ac32
Summary:
Scrubbing a repo is highly concurrent as its mostly IO bound. As such we can end up waiting on sql connection pool for connections where it allows less than scheduled_max connections.
This change makes bounded_traversal_unique calls from the walker aware of the database tier and shard a Node may connect to, so that execution can be limited to the bounds of what the connection pool can support without waiting.
We still end up waiting for the connection, but now it's done in bounded_traversal_unique, rather than in connection pool code, and are thus a) able to process other Nodes while waiting and b) not subject to connection pool timeouts.
Differential Revision: D26524074
fbshipit-source-id: 19125388c730f5cef7e9de34b5b550efa8e6b825
Summary: Small clean up. Allows us to pass Logger by reference, removing the FIXME in blobrepo factory
Reviewed By: farnz
Differential Revision: D26551592
fbshipit-source-id: d6bb04b8bb3034ad056f071b67b5ae0ce3c6f224
Summary:
Allow color effects to be joined with `+`, e.g. `blue+bold`. Unlike effects
separated by spaces, these effects must all be available in order for the
effect to apply. If any of the effects are not available, then the combined
effect is not valid.
This is useful in fallback chains, where some of the fallbacks are combined
effects, for example: `brightred:red+bold`.
Use these to improve the fallback chains for sparse profiles, so that the
profile names are not shown in black on 8 color terminals.
Reviewed By: quark-zju
Differential Revision: D26580365
fbshipit-source-id: 8e204c901566ac03fb4af066ab1a09142750a9fb
Summary: I removed tokio-compat yesterday but this landed at the same time and uses it.
Reviewed By: mitrandir77, StanislavGlebik
Differential Revision: D26605246
fbshipit-source-id: 189f485bc8bc3018abb3e9290953eba14bd178de
Summary: It's useful to know the max number of connections to a shard that it is sensible to open. Used in next diff in stack.
Differential Revision: D26543419
fbshipit-source-id: 57e7c3295a5b5db1572f26954ae0dfb04c84b374
Summary:
The walker mostly checks for duplicates before emitting a new edge, at the same time recording the edge as visited to prevent duplicate edges.
However for derived data where the node may or may not be present, the node isn't considered visited until the node data is successfully loaded and seen in state.rs record_resolved_visit().
In such cases multiple copies of a node could be enqueued, and then we need to run each one.
With this change, where the walker can detect that such a step has completed previously, it will now short circuit the step and return None.
Differential Revision: D26369917
fbshipit-source-id: c2bdbbabfaa80dbb7cc7d2bc25a17230531ae111
Summary:
LOOKUP is the next RPC that EdenFS needs to implement, let's start by adding
the RPC types.
Reviewed By: kmancini
Differential Revision: D26562919
fbshipit-source-id: 3a4ce1a039b6405df9ff94757963aa46acf56d92
Summary:
The ACCESS RPC merely tries to see if a client can perform some action on a
file/directory. Until we have a better story around checking the RPC
credentials and passing it around, let's just return the requested access
rights as-is.
Reviewed By: kmancini
Differential Revision: D26562918
fbshipit-source-id: 468e038cc063c289b5554f3faa6a7f99be2731e4
Summary: This merely add the types necessary to implement the ACCESS RPC
Reviewed By: kmancini
Differential Revision: D26562920
fbshipit-source-id: 2f3238e723e97a54896fabb026adf9b92ab4fcd3
Summary:
Take 2 of fixing the lifetime issues of the RpcServer, this time, the
RpcAcceptCallback needs to live for longer than RpcServer itself. This is due
to the acceptStopped callback being called after RpcServer is being destroyed.
Since the RpcServer needs to be destroyed in the EventBase thread, the
acceptStopped callback is delayed, causing it to be invoked after the RpcServer
has freed its memory.
To solve this, we simply need to make the RpcAcceptCallback a delayed
destructor, and hold a reference to itself that goes away once the
acceptStopped callback is called.
Reviewed By: kmancini
Differential Revision: D26556644
fbshipit-source-id: 32cd80f1664649c1ad96f88c4eec6dd2ed6e8c12
Summary:
Now that the privhelper has the necessary code to unmount an NFS mount, let's
do it. With this in place, this enables `eden mount` and `eden unmount` for NFS
mounts. Unfortunately, it appears that during unmount, releasing the Nfsd3
object triggers a use-after-free in the rpc code
Reviewed By: kmancini
Differential Revision: D26500109
fbshipit-source-id: a210761f818b28b1eb0044f7314a0e2b9017848c
Summary:
This is merely fixing a typo that I made previous where I reused the prjfs
request timeout instead of adding a new one.
Reviewed By: kmancini
Differential Revision: D26500110
fbshipit-source-id: b9bf0cbc0d74866cdc2471f126751d6d8e514e21
Summary:
Now that `mount(2)` complete, we can start plumbing the rest of the mount code
to accomodate for NFS. Trying to find a common ground between Prjfs, FUSE and
Prjfs is harder than I wish it would be and thus I wasn't able to find a
satisfatory solution. For now, I went with a std::variant that stores either a
FuseChannel, or the Nfsd3. In the future once Nfs is stabilized and we have a
good understanding of how it differs (and where it doesn't), EdenMount would
probably need a good refactoring.
Reviewed By: kmancini
Differential Revision: D26500111
fbshipit-source-id: f02a2eaf8890261f150d7cdd2cdfd134aa62c2aa
Summary:
Adding a new configuration that instantiates SegmentedChangelog by downloading
a dag from a prebuilt blob. It then updates in process.
Reviewed By: krallin
Differential Revision: D26508428
fbshipit-source-id: 09166a3c6de499d8813a29afafd4dfe19a19a2a5
Summary:
I am not sure if this too abstract. It might be. This however has separation of
concerns :)
The goal here is to end up with an in memory IdMap that we write to and read
from first. For things that are not found in the in memory IdMap we fall back
to the SqlIdMap. We'll end up with something like:
`OverlayIdMap(ConcurrentMemIdMap, SqlIdMap)`
Reviewed By: quark-zju
Differential Revision: D26417642
fbshipit-source-id: b2b310306db4dc9fc3427bbf50b19366160882a9
Summary:
The `MemIdMap` is not a valid `IdMap` implementation because it takes `&mut
self` when doing inserts. Wrapping the IdMap in a `RwLock` allows us to
implement the `IdMap` trait.
Reviewed By: krallin
Differential Revision: D26417643
fbshipit-source-id: cb5e3513841fa1dd7c8b8004ce7b2fe1467983d7
Summary:
The on demand update code we have is the most basic logic that we could have.
The main problem is that it has long and redundant write locks. This change
reduces the write lock strictly to the section that has to update the in memory
IdDag.
Updating the Dag has 3 phases:
* loading the data that is required for the update;
* updating the IdMap;
* updating the IdDag;
The Dag can function well for serving requests as long as the commits involved
have been built so we want to have easy read access to both the IdMap and the
IdDag. The IdMap is a very simple structure and because it's described as an
Arc<dyn IdMap> we push the update locking logic to the storage. The IdDag is a
complicated structure that we ask to update itself. Those functions take
mutable references. Updating the storage of the iddag to hide the complexities
of locking is more difficult. We deal with the IdDag directly by wrapping it in
a RwLock. The RwLock allows for easy read access which we expect to be the
predominant access pattern.
Updates to the dag are not completely stable so racing updates can have
conflicting results. In case of conflics one of the update processes would have
to restart. It's easier to reason about the process if we just allow one
"thread" to start an update process. The update process is locked by a sync
mutex. The "threads" that fail the race to update are asked to wait until the
ongoing update is complete. The waiters will poll on a shared future that
tracks the ongoing dag update. After the update is complete the waiters will go
back to checking if the data they have is available in the dag. It is possible
that the dag is updated in between determining that the an update is needed and
acquiring the ongoing_update lock. This is fine because the update building
process checks the state of dag before the dag and updates only what is
necessary if necessary.
Reviewed By: krallin
Differential Revision: D26508430
fbshipit-source-id: cd3bceed7e0ffb00aee64433816b5a23c0508d3c
Summary:
This structure is going to be useful to implement the SegmentedChangelog
functionlity for the OnDemandDag as we move forward with separate objects for
the iddag and the idmap rather than a direct dependency on a Dag object.
Reviewed By: quark-zju
Differential Revision: D26508429
fbshipit-source-id: 9116f1c82d301e8e5b726966abd2add2e32765d6
Summary:
Moving all update logic to `dag::update`.
Additional minor changes: removing Dag::build and spliting build_incremental
around the mutable update section of iddag.
Reviewed By: krallin
Differential Revision: D26508427
fbshipit-source-id: 984259d2f199792fcf0635dd3100ec39260fd3ed
Summary:
This is going to be useful when we update the InProcessDag on the server. As
opposed to taking a lock for everything we will be able to take a short lock
to update the IdMap and then a short lock to update the IdDag.
Reviewed By: krallin
Differential Revision: D26417621
fbshipit-source-id: 43f342d384f1be80dcfe721de659ac3ce9dd0e7b
Summary:
Some features in debushell, like `%time` uses `locals()`. They currently cannot
use common variables like `cl` like:
In [1]: %time len(cl)
---------------------------------------------------------------------------
NameError Traceback (most recent call last)
<timed eval> in <module>
NameError: name 'cl' is not defined
Fix it by updating `locals()`.
In [1]: %time len(cl)
CPU times: user 700 µs, sys: 130 µs, total: 830 µs
Wall time: 1.28 ms
Reviewed By: ikostia
Differential Revision: D26590943
fbshipit-source-id: 2b7fd3274f1ea41f7996edbbdae0af8e103a9c0a
Summary:
The EdenFS import helper's `_fetch_tree_impl` method works by either calling `repo._prefetchtrees` or `repo.prefetchtrees`, both of which are methods from `treemanifest` extension's `treerepository` class. Unfortunately, these methods are lower-level than their names would suggest, and will always perform gettreepack style fetching (see [1]).
If HTTP fetching is enabled, this means that EdenFS will always query EdenAPI's `/complete_trees` endpoint instead of `/trees`, which is needlessly expensive given that EdenFS just wants the exact set of trees specified. As a somewhat hacky workaround, this diff just checks whether HTTP fetching is enabled, and if so, directly calls the appropriate HTTP fetch method.
This solution isn't ideal; it would be better for the import helper to request the trees from Mercurial's `remotetreestore` instead of via methods from `treerepository`. Unfortunately, with the current structure of Mercurial's storage layer, the `remotetreestore` isn't readily accessible because it gets passed into the Rust API's storage hierarchy upon construction.
---
[1]: The various `*prefetchtrees` methods are usually called from Mercurial's `remotetreestore`, which is where the choice of tree fetching strategy is made (i.e., designated nodes vs gettreepack). The `remotetreestore` then calls `*prefetchtrees` for gettreepack-style fetching, or `*getdesignatednodes` for on-demand fetching. As such, a call to `*prefetchtrees` generally implies gettreepack-style fetching.
Reviewed By: quark-zju
Differential Revision: D26560451
fbshipit-source-id: 2eedf50a6e66fac78df77214b777544eb8049714
Summary:
Comments affecting runtime behavior disturbs me, so use explicit
structopt annotations on help text. And move those annotations to the
command implementations.
Reviewed By: fanzeyi
Differential Revision: D26412452
fbshipit-source-id: 066dfdd1c54254bae4bd2af65031487b7a1094da
Summary: clap/structopt adds a -V flag to every subcommand by default. Disable that.
Reviewed By: fanzeyi
Differential Revision: D26412093
fbshipit-source-id: 03a0320fd15444f700b359f5ed0ca8c40b10ae1c
Summary:
I don't want the fallback when testing, so add an environment variable
for bypassing it.
Reviewed By: fanzeyi
Differential Revision: D26411754
fbshipit-source-id: f2aea82bf3e79db11e72ad5f5ce33513cfc2f05b
Summary:
Rather than offloading dealing with unexpected errors to each
subcommand, allow them to propogate out. Subcommands can still be
responsible for handling expected "errors" like EdenFS not running.
Reviewed By: fanzeyi
Differential Revision: D26411186
fbshipit-source-id: 4e1c5fb1d7bed495e3e22cca44d3f84f7f4c7f14
Summary:
We should be consistent about how we render mode_t across all of the
FUSE requests.
Reviewed By: singhsrb
Differential Revision: D26286527
fbshipit-source-id: aadf247c0621be79525c4df2da2940c02ee27719
Summary:
In EdenAPI this is logged as a vector (and in all our other services), but in
Mononoke Server we log it as a string. Let's fix this up. This is worth doing
now since right now we end up logging to 2 columns with the same name and a
different type.
Reviewed By: ahornby
Differential Revision: D26542737
fbshipit-source-id: 2f12c9e475061b1c21c71bade99b83cc070006e8
Summary:
The earlier diffs in this stack have removed all our dependencies on the Tokio
0.1 runtime environment (so, basically, `tokio-executor` and `tokio-timer`), so
we don't need this anymore.
We do still have some deps on `tokio-io`, but this is just traits + helpers,
so this doesn't actually prevent us from removing the 0.1 runtime!
Note that we still have a few transitive dependencies on Tokio 0.1:
- async-unit uses tokio-compat
- hg depends on tokio-compat too, and we depend on it in tests
This isn't the end of the world though, we can live with that :)
Reviewed By: ahornby
Differential Revision: D26544410
fbshipit-source-id: 24789be2402c3f48220dcaad110e8246ef02ecd8
Summary:
This was a thing that was only ever used in Mononoke, and we don't think it's
usable and haven't been using it. Let's get rid of it. As-is, it won't even work
for most people due to its (indirect) dependency on Tokio 0.1.
Reviewed By: StanislavGlebik
Differential Revision: D26512243
fbshipit-source-id: faa16683f2adb20dfba43c4768486b982bc02ff9
Summary:
By passing the argument to the channel, we can make it so that the NFS code
correctly replies to whether it is case sensitive or not.
Reviewed By: kmancini
Differential Revision: D26500112
fbshipit-source-id: 2988eae403ff3648b50a1a8f0c978be2828ba568
Summary: This code has been used to transfer an existing repo to remotenames. After D26460435 (84280e36c3) it doesn't work as designed and should be removed as well.
Reviewed By: quark-zju
Differential Revision: D26544739
fbshipit-source-id: 34c08d4b9997c0b1f298ee1ecd0e8af24f4d8a39
Summary:
Support for unsubscribing from a scratch remote bookmarks in `hg hide` command.
This is support if you hide via a revision. Hiding by its name will be another change.
Reviewed By: quark-zju
Differential Revision: D26544305
fbshipit-source-id: d10372513dda88903e2cc031ff16883a001c8e34
Summary: We don't log this information if a request failed. Let's start doing that.
Reviewed By: farnz
Differential Revision: D26577832
fbshipit-source-id: acfac1c57364eeb457a81ff4bbeddc5407f3a985
Summary: Can remove Clone constraint and no need for Arc with some code tidyups
Reviewed By: farnz
Differential Revision: D26575852
fbshipit-source-id: 0cd31879c6d72cc7242e1c34ef5df07c96ac6e6c
Summary:
The `commit` or `amend` command might not have been the first item in the
command list (e.g. there could have been a custom config option). Expand the
heuristics for detecting the `commit` and `amend` cases to account for this.
Reviewed By: quark-zju
Differential Revision: D26545339
fbshipit-source-id: a5b1fc8ccc87989e742fce1fa79273266892ed79
Summary: Dynamic config only gets applied once the local repo is instantiated, but source peer is created long before that. This causes it to have missing configuration when being instantiated. Apply dynamic config much earlier in case of a clone so that srcpeer can use dynamicconf as well.
Reviewed By: DurhamG
Differential Revision: D26543635
fbshipit-source-id: 88c16d345f5116bfaaf57c593eb09145df81b4fb
Summary:
This diff ensures no one can exploit mkscratch's scratch directory. In reality probably no one would do this but just to add it as a precaution.
And also the renaming, I didn't land the rename changes in my previous diff and this diff fix that so we don't roll the "nested" mode name out.
Reviewed By: xavierd
Differential Revision: D26526702
fbshipit-source-id: 04ec883e4d1c0c3e9b54b6274e5113c8b4845b3f
Summary:
This warning was printed by old checkout, keeping it in nativecheckout too
The warning tells user that current working directory was removed during checkout
This diff also makes test-update-names.t to use nativecheckout. Otherwise last test fails on remote repo, because pyworker does not emit the deleted cwd warning
Reviewed By: quark-zju
Differential Revision: D26558188
fbshipit-source-id: 1f6ea2ea1ac7358ce2f06fed25069656481b30e6
Summary: After this update, test-update-names.t tests are using native checkout when congfig is set
Reviewed By: quark-zju
Differential Revision: D26558186
fbshipit-source-id: f70f65344b5f2209f313e3edd5fd7f541318459a
Summary: Those shortcuts can be used to setup remote repo via single line
Reviewed By: quark-zju
Differential Revision: D26558187
fbshipit-source-id: c6fd48ed38cc4dbaad4db714c4dfd76ec26bf608
Summary: This is needed to correctly show status after checkout
Reviewed By: quark-zju
Differential Revision: D26551119
fbshipit-source-id: 3ab576df8132b1fb8cccf507717923ecf3084757
Summary:
This diff makes CheckoutPlan::apply take &self instead of self, so that CheckoutPlan can be preserved.
This result in cloning of some paths(but realistically, they probably get moved anyway in this code path, so this should not have perf impact)
This will simplify pycheckout as it will allow to keep plan and later use it to update dirstate
This diff also exposes accessors for dirstate update (e.g. removed_files / updated_content_files / updated_meta_files)
Reviewed By: quark-zju
Differential Revision: D26551118
fbshipit-source-id: 4e2d02da0a692345eae7d5e7124663c577e9029c
Summary:
Currently native checkout works only on simplest cases when there is no merge / rebase and working copy is clean
Additionally, all native checkout logic is gated with experimental.nativecheckout config
Reviewed By: quark-zju
Differential Revision: D26501903
fbshipit-source-id: 2c1b2fd303f1cb1f461d4854ea60a7274ae38732
Summary:
By moving the createChannel outside of the EdenMount class, we no longer need
the channelType alias, so let's do it.
Reviewed By: kmancini
Differential Revision: D26500113
fbshipit-source-id: f992ed2aaac5d692d316d06340bf9b219a2d7006
Summary: The RPC just translate the various `struct stat` fields into the fattr3 ones.
Reviewed By: kmancini
Differential Revision: D26389793
fbshipit-source-id: 48c6e109d5d2cb62cab096114c37314d7833035f
Summary:
Make the status fast path print warnings about non-utf8 names and continue on
other valid utf-8 names. It matches the behavior of the Python status code
path.
Before this change, an invalid utf-8 name would just print:
abort: invalid utf-8 sequence of 1 bytes from index 7
without telling which file it is.
Reviewed By: markbt
Differential Revision: D26553514
fbshipit-source-id: 6e26a2a8d738e9001d878a80c0dc82ae6d18a97c
Summary:
Similar to D26142175 (324f47b1f0), initialize the logger that writes to the error stream of
IO.
Reviewed By: sfilipco
Differential Revision: D26518014
fbshipit-source-id: 2547f4a8f3dba1f624fd00798672f1148869e250
Summary:
Add an API to obtain an `io::Write` object for the error stream.
It will be used by next changes.
Reviewed By: sfilipco
Differential Revision: D26518021
fbshipit-source-id: bc39fa54f83be8ff2c8fbc803700c4fe57e814bd
Summary:
Make it possible for IO to be cloned. This allows, for example, tracing or
progress bar logic to keep a reference of IO.
Reviewed By: sfilipco
Differential Revision: D26518028
fbshipit-source-id: d5ca7f4347251c68f7491f784f647ee80c47d159
Summary:
We're going to tweak the internals of IO. Making its fields private to allow
that.
Reviewed By: sfilipco
Differential Revision: D26518023
fbshipit-source-id: a1eed46f4f87a3b4b63e56be733102058b4d72d6
Summary: Add parking_lot dep. It will be used later.
Reviewed By: sfilipco
Differential Revision: D26518019
fbshipit-source-id: 76124a2f70731b30017a6d7019eef9dc856fe54a
Summary: In preparation for adding C++ client alternatives, use a wrapper around the Thrift client. This currently just calls the Thrift client directly, but will grow the ability to call the C++ client, too. For now, there's a dummy parameter to control the use of the C++ client.
Reviewed By: ahornby
Differential Revision: D26513598
fbshipit-source-id: b26cd9a9d89ab0502510b8533df4a60f5ca65292
Summary:
The changes (and fixes) needed were:
- Ignore rules that are not rust_library or thrift_library (previously only ignore rust_bindgen_library, so that binary and test dependencies were incorrectly added to Cargo.toml)
- Thrift package name to match escaping logic of `tools/build_defs/fbcode_macros/build_defs/lib/thrift/rust.bzl`
- Rearrange some attributes, like features, authors, edition etc.
- Authors to use " instead of '
- Features to be sorted
- Sort all dependencies as one instead of grouping third party and fbcode dependencies together
- Manually format certain entries from third-party/rust/Cargo.toml, since V2 formats third party dependency entries and V1 just takes them as is.
Reviewed By: zertosh
Differential Revision: D26544150
fbshipit-source-id: 19d98985bd6c3ac901ad40cff38ee1ced547e8eb
Summary:
I'm going to start shifting from Thrift to C++ client - to make reuse easier, put the Thrift client in its own module, with the Thrift-specific tests, and put shared tests in a shared module.
While in here, rename the blobstore to ManifoldBlobstore, so that it's clear that it's not just a Thrift blobstore, ready for it being a mix of C++ and Thrift.
Reviewed By: ahornby
Differential Revision: D26513599
fbshipit-source-id: 9e111583f1700eea18e83032b9ca1b9c8babc83e
Summary: Introduce `FetchError` type, with separates "not found" errors (which require a key), from other errors (which may or may not have an associated key). This allows us to easily fall back for only "not found" errors propagate other fetch errors to the caller. The current version of `FetchError` still does not eliminate redundantly storing the key for cases like EdenApi, where the key may be part of the error type itself. This optimization may not be worthwhile after we refactor these store implementations to use `HgId` instead of `Key`.
Reviewed By: kulshrax
Differential Revision: D26410215
fbshipit-source-id: e6198d54de64b41ff696cabd64affc8dbaa41cf9
Summary: Add a wrapper type, `LegacyDatastore`, along with a `ReadStore` implementation that reads via the `HgIdDataStore` trait, for any wrapped types which implement that trait.
Reviewed By: kulshrax
Differential Revision: D26381207
fbshipit-source-id: d28dc3095adf20403f8b993d5a939d1e41c77462
Summary:
Added a new `ReadStore` implementation for EdenApi `FileEntry`s. This is pretty much identical to the `TreeEntry` implementation, but calls the `files` method instead, which does not yet support attributes or per-entry errors (although they are both supported on the wire).
I re-use the type-agnostic indexedlog `Entry` adapter for file support for now, to keep things minimal. This unfortunately means the output type of the `Fallback` combinator is a bare `Entry` for both files and trees, losing us some type safety, but I think this is acceptable for now, until I eventually introduce type-safe constructors and value types. Making the file and tree value output types distinct will only be necessary with the introduction of attribute support, or when we'd like to move away from using an "opaque blob" representation for them.
Reviewed By: kulshrax
Differential Revision: D26348577
fbshipit-source-id: 1a930af6e4b5b4d8bacd266c3e51db96cee92dbd
Summary:
Added write support to the `FallbackStore` combinator, along with a flag to control writing to the write store. This enables the "preferred" store to act as a read-through cache for the "fallback" store, with an optional "read only" mode via the "write" flag.
Currently, errors in the write path are silently ignored.
Reviewed By: kulshrax
Differential Revision: D26233602
fbshipit-source-id: acce020a877b87bfee87763e984923c7c51b2b17
Summary: Introduces a minimal WriteStore trait, with a basic implementation for IndexedLog. Currently, there's no explicit key in the `WriteStream`. Instead, it is implicit that the value type to be written should contain a key. In the future, we may introduce an abstraction over value types which do and do not contain a key.
Reviewed By: kulshrax
Differential Revision: D26213028
fbshipit-source-id: 75867ff7229d594346e7e7624e8ca91f8205fed4
Summary: This helps with pipelining (once chunk is prefetched it will start rolling out to fs) and also helps with limiting number of keys prefetched at once
Reviewed By: quark-zju
Differential Revision: D26496789
fbshipit-source-id: 9aa6b08c1605ab2a06a02347897f5dcfa22297fd
