Summary: This diff uses filescmstore for native checkout when nativecheckout.usescmstore config is set
Reviewed By: DurhamG
Differential Revision: D27658844
fbshipit-source-id: ec3442d677ccb25e8b08cc194e4c8c18c0e01fa1
Summary:
This diff introduces CheckoutPlan::apply_read_store to apply checkout plan using ReadStore as a data source
This requires some minor changes in apply_stream flow as ReadStore does not guarantee ordering of returned files
Reviewed By: DurhamG
Differential Revision: D27658346
fbshipit-source-id: 5a289554d8dd7b6bb4b5a996659cd0661779ad5f
Summary: The latter is more lightweight.
Reviewed By: DurhamG
Differential Revision: D27641665
fbshipit-source-id: d46f62f9067eb9cb4c8517a62efa6f663d4b6732
Summary: The latter is more lightweight.
Reviewed By: DurhamG
Differential Revision: D27641669
fbshipit-source-id: d907407f5a6e868862fe37f1f67fbe99ee378156
Summary: The latter is more lightweight.
Reviewed By: DurhamG
Differential Revision: D27641667
fbshipit-source-id: adce5a39fcb5d8e8d5d989fed46991e20ab3710d
Summary: Provides a way to read config with lighter dependencies.
Reviewed By: DurhamG
Differential Revision: D27641668
fbshipit-source-id: fc99a78f5f51e63f61d1b049af74f61f5d1916a3
Summary:
The `configparser` is now too heavyweight. Some other crates (ex. io, auth,
revisionstore) just want to extract config values without complicated parsing /
remote hotfix logic.
Add a configmodel crate to satisfy the need.
Reviewed By: DurhamG
Differential Revision: D27641666
fbshipit-source-id: 26bd0b606ae3d286b3ec218927aef726d6802c63
Summary: Add a new `http.verbose` config option that turns on verbose output for libcurl (similar to the output printed by `curl -v`). This can be very useful for debugging HTTP issues.
Reviewed By: DurhamG
Differential Revision: D27693304
fbshipit-source-id: 2ad7a08889f40ffbcd2f14ac9c21d70433629da4
Summary: Make this method match the behavior of `remotefileslog.memcachestore` and cache the `edenapistore` instead of constructing a new one each time. Right now this doesn't matter too much because we currently only call this once when setting up the Rust `revisionstore`, but it would be good to avoid creating multiple instances if we do start using this elsewhere.
Reviewed By: DurhamG
Differential Revision: D27684210
fbshipit-source-id: 7987f603c79758902b4740dd8b46d26a25baec93
Summary:
This diff causes memcache to be disabled when `remotefilelog.cachekey` is set to the empty string, thereby allowing memcache to be disabled on the command line with `--config remotefilelog.cachekey=''`. This is useful when testing data-layer changes.
Previously, the only way to do this was to add `%unset cachekey` to the `remotefilelog` section of your `hgrc`, which was a bit tedious compared to just using a `--config` flag.
Reviewed By: DurhamG
Differential Revision: D27683782
fbshipit-source-id: 3e0434e98a32db916a07935e8b26f70317f50286
Summary: The error is not going to have a message in many cases leading to crashes.
Reviewed By: quark-zju
Differential Revision: D27637119
fbshipit-source-id: 135b133371916dddf0c47a84f00957a8b8fdfe92
Summary:
`const_cstr::ConstCStr` is represented internally as a fat pointer with fixed size: `&'static str`. See https://docs.rs/const-cstr/0.3.0/const_cstr/struct.ConstCStr.html. Notably this is **different** from the representation of `std::ffi::CStr`, which is a dynamically sized type and normally passed around behind a reference, as `&CStr`. Using `&ConstCStr` in signatures, which is effectively like `&'a &'static CStr`, is confusing due to the discrepancy between the two relatedly named types. Additionally having two different lifetimes involved -- the static lifetime of the underlying bytes, and the short lifetime of the fat pointer -- is unnecessarily confusing when async code and a language boundary are involved.
The utf8-cstr crate uses what seems like a better representation to me than the const-cstr crate. See https://docs.rs/utf8-cstr/0.1.6/utf8_cstr/struct.Utf8CStr.html. `Utf8CStr` is the dynamically sized type, just like `CStr`. Then `&'static Utf8CStr` is how it would commonly be passed around, just like `&CStr`.
Reviewed By: krallin
Differential Revision: D27698169
fbshipit-source-id: ffe172c2c2fc77aeab6b0a0a8aed3e3c196098cc
Summary:
We want to handle the case where the client has multiple heads for master. For
example when master is moved backwards (or when it get moved on the client by
force). Updating the client code to thread the list of master commits to the
EdenApi client.
Reviewed By: quark-zju
Differential Revision: D27523868
fbshipit-source-id: db4148a3f1d0e8b0b162e0ecc934e07f041c5511
Summary:
We want to handle the case where the client has multiple heads for master. For
example when master is moved backwards (or when it get moved on the client by
force). Updating the request object for HashToLocation to send over all the
master heads.
When the server builds non-master commits, we will want to send over non-master
heads too. We may consider having one big list of heads but I think that we
would still want to distinguish the non-master commit case in order to optimize
that use-case.
Reviewed By: quark-zju
Differential Revision: D27521778
fbshipit-source-id: cc83119b47ee90f902c186528186ad57bf023804
Summary:
`panic!()`, and things which use `panic!()` like `assert!()`, take a literal format
string, and whatever parameters to format. There's no need to use `format!()`
with it, and it is incorrect to pass a non-literal string.
Mostly it's harmless, but there are some genuinely confusing asserts which
trigger this warning.
Reviewed By: dtolnay
Differential Revision: D27672891
fbshipit-source-id: 73929cc77c4b3d354bd315d8d4b91ed093d2946b
Summary:
Modify the `Debug` implementation for `minibytes::Bytes` to use `std::ascii::escape_default` to debug print a `Bytes` as an ascii-escaped bytestring.
For comparison, the `bytes` crate `Bytes` type provides the same functionality, though it doesn't use the standard library `escape_default` function: https://docs.rs/bytes/1.0.1/src/bytes/fmt/debug.rs.html#39-43
This change greatly improves the output of the `debugscmstore` command. If we don't want to make this the default behavior, we can provide a formatting wrapper type or I can specialize the output in `debugscmstore`, but I can't see any real downsides, especially given the `bytes` crate does the same thing, and we have a similar specialization for `HgId` (hex format in that case).
Reviewed By: quark-zju
Differential Revision: D27642721
fbshipit-source-id: 8faba421fa5082a2098b13ef7d286e05eccb6400
Summary: Add the `with_key` function to `Entry`, which replaces it's key with a provided key. Currently, scmstore returns incorrect results when multiple entries exist with different paths but the same HgId (as scmstore directly returns the path found on disk locally). This isn't a problem in the legacy API, which returns a bare `Vec<u8>` content, which is implicitly associated with the requesting key because it is the result of a single `get` call, or is irrelevant because the `prefetch` method doesn't directly return the results.
Reviewed By: andll
Differential Revision: D27664025
fbshipit-source-id: 014d44ca9a1dc2721685622fd2b077ed3483838f
Summary:
D27659634 (8e8aaa61d6) removed these files, so let's drop their exclusions from
test-check-code.t
Reviewed By: sfilipco
Differential Revision: D27682136
fbshipit-source-id: f8e10fac37ea90fb2782b960faf4536f1ff9133b
Summary:
fctx is not guaranteed to have the _path and _filenode attributes. Those are
specific to implementations, e.g. `absentfilectx` does not have them.
`basefilectx` instead defines the `path()` and `filenode()` for general fctx
use.
Reviewed By: quark-zju
Differential Revision: D27667176
fbshipit-source-id: 1d7889d264b597665ef05f84a752323f078cb455
Summary:
Those are not used. Recently we saw build issues like:
lib/third-party/sha1dc/sha1.c:8:10: fatal error: string.h: No such file or directory
#include <string.h>
^~~~~~~~~~
Possibly by some compiler flags disabling stdlib. Since we don't need
the C code let's just remove them.
Reviewed By: singhsrb
Differential Revision: D27659634
fbshipit-source-id: b8fcac4f05be95cac470f9b4830baf76e06f98ad
Summary:
Defend against the possibility of `nodeinfo["remote_bookmarks"]` being `None`
by treating it the same as an empty list.
Reviewed By: quark-zju
Differential Revision: D27658994
fbshipit-source-id: 06c31bdba2cc6cbd82f5bd718befd6be9bb233f2
Summary:
The `python` in `PATH` might be the fbcode Python that has `-nostdinc` in its
`CFLAGS`. That Python is problematic because it cannot compile C extensions.
Reviewed By: DurhamG, markbt
Differential Revision: D27661488
fbshipit-source-id: 243205522fcaf53d5af6a3c9afc4d28160072de5
Summary:
a [git worktree](https://git-scm.com/docs/git-worktree) allows for a single repository to have multiple local checkouts in different directories (allowing parallel work on multiple branches of the same repo).
in such a worktree, `.git` is a file and not a directory:
```
$ cat .git
gitdir: /path/to/actual/repo/.git/worktrees/name
```
the `_git_prompt` helper in `scm-prompt.sh` expects only directories:
```
$ echo "$(_git_prompt /path/to/worktree/.git)"
# (output is empty)
```
this amends the helper to support them:
```
$ echo "$(_git_prompt /path/to/worktree/.git)"
f140443f|REBASE-i|T123456
$ echo "$(_git_prompt /path/to/parent/.git)"
T54321
```
Reviewed By: quark-zju
Differential Revision: D27509147
fbshipit-source-id: 9a4ab55af99538c6425ad5721c3266386dbda453
Summary:
The "filter" set's filter function might not be prepared for inputs outside
the parent set. So let's the "contains" function to test against the parent
set first, then test the filter function.
This fixes the "merge()" set's "contains" check using the revlog backend:
In [1]: v=repo.revs('draft() & merge()')
In [2]: v._set
Out[2]: <meta ?>
In [3]: m.node.nullid in v._set
Out[3]: False
Before this diff it would be:
In [3]: m.node.nullid in v._set
CommitLookupError: '0000000000000000000000000000000000000000 cannot be found'
Note: Segmented changelog backend is not affected because it does not use
filter sets.
Reviewed By: xavierd
Differential Revision: D27657502
fbshipit-source-id: 30bb261fea59bdc5644580e98796f52fa93c2705
Summary: This API has moved in Python 3. This is only used for util.popen4 calls, which aren't super frequent, so it escaped notice until now.
Reviewed By: sfilipco
Differential Revision: D27603246
fbshipit-source-id: 9ee6af4f66380480fe6c1c736287231464d0b21e
Summary: We were accidentally not setting the TLS key here; this diff fixes it.
Reviewed By: quark-zju
Differential Revision: D27634276
fbshipit-source-id: 9aac3a34b6f6655059a8d3332eea8ba02d062651
Summary:
Usage is hidden under config experimental.nativerebase
When config is set, we attempt to execute native rebase, and check if it has conflicts
If there are no conflicts, we convert native rebase result into Python actions
In case of conflicts, we currently just fallback to python merge
Reviewed By: DurhamG
Differential Revision: D27482909
fbshipit-source-id: 5705d372095f64ce0c6ee93c783e1c8dccf8b11a
Summary:
This diff contains proposal for basic rebase model for new checkout.
This diff introduces two types of file changes - basic no conflict Actions(that will replace CheckoutPlan actions) and ConflictAction for actions that contain conflicts
No conflict actions are produced when comparing two manifests
Conflict actions can be produced when rebasing manifests.
Eventually we will adjust checkout code to take either list of Actions or Conflict actions and perform corresponding operations on the file.
Rebase::rebase is used to generate list of conflict actions when rebasing.
Currently `Rebase::rebase` produces list of actions on top of 'base' commit.
Before doing actual checkout we will need to take into account what current commit is and adjust this list of actions accordingly (however, this adjustment will be trivial, it won't produce more conflicts)
After getting adjusted list of actions, checkout code can roll it out to fs and call merge drivers if needed.
In the future, if we will want to allow check in conflicts, we will need to adjust `Rebase::resolve_conflict` to take `ConflictAction` as input, instead of an Action.
Reviewed By: DurhamG
Differential Revision: D27028001
fbshipit-source-id: b02b7ad8030fcf146b53639d69e66fdc8f38a62d
Summary:
The nameset._set.iter() used by nameset.{fastdesc,fastdesc} do not know how to
prefetch. Just make them return `None` in this case. This addresses issues
where `log` can trigger one-by-one fetching.
hg log -r "limit(all(), 100000, 100000) & date('2021-04-01')"
The stack is a bit deep, it is:
# cmdutil.getlogrevs
if not revs:
...
# smartset.filteredset.__nonzero__
fast = None
candidates = [self.fastasc, self.fastdesc]
...
if fast is not None:
it = fast()
Basically filteredset calls into its _subset (nameset)'s fast{asc,desc},
which does not do prefetch properly and that cause filteredset.__nonzero__
to be slow.
Reviewed By: sfilipco
Differential Revision: D27634020
fbshipit-source-id: c3a44a1eb81c32f4dccb319ce42a15c56121c2ec
Summary: introduce a way of requesting unhydrated commits using client telemetry
Reviewed By: StanislavGlebik
Differential Revision: D27591868
fbshipit-source-id: 7616f9d3b222c2c7f43c2ba930086eb0ec9e15bc
Summary:
Only used by one test that can define the constaint itself.
The problem with having it on the trait is that it's a bit noisy when
things operate on ToApi at the generic level. It adds to the list of
constaints they these users of the ToApi trait need to add.
Reviewed By: kulshrax
Differential Revision: D27549922
fbshipit-source-id: fff9e513eb4c06862111ce6eecc84ab981eea893
Summary:
This is only used in one utility which can define the constaint itself.
I am looking to simplify the Requirements for ToWire so that we can more
easily iterate on them. Debug as a requirement produces too much noise.
There is the risk of ending up in a scenario where we want to print the Wire
type but it's more practical to annotate structs with derive Debug when that
happens than to add the constaint in the trait.
Reviewed By: kulshrax
Differential Revision: D27549925
fbshipit-source-id: aacf7c1c465c94414be02aa143187897c7084980
Summary:
There is no use for it outside of one test which can describe that constraint
itself.
I think that requiring ToWire and ToApi to use the same objects is too much
for the general use case. We regularly convert between different object types
that are the same logical thing but have different representations. A good
example for that is the HgId. It makes sense to implement ToWire for all HgId
variations.
Reviewed By: kulshrax
Differential Revision: D27549924
fbshipit-source-id: d76d7a4beb528634bed46ae93dbd634d850547e5
Summary:
For async requests, we perform a blocking request in a separate thread, and stream the results back through a channel. However, if the curl handle for the request is dropped before starting the request (for example, because of a configuration error), this function would return a `oneshot::Canceled` error (from the channel consumer) instead of the real error message from the IO thread.
This diff fixes the issue by ensuring that the function waits for and returns the error message from the IO thread in the event that the IO thread returns before starting the request.
Reviewed By: quark-zju
Differential Revision: D27584502
fbshipit-source-id: 8447c158d253c3f28f03fcc4c36a28698fe6e83d
Summary:
This adds command line argument `-I` that supplies \0-separated list of files to add to commit.
Added files can be ignored/untracked.
No limit on total size for now, still waiting to hear from mononoke team on max files size
Reviewed By: quark-zju
Differential Revision: D27547822
fbshipit-source-id: 8bb755db5dd6e557e2752381dbeb5f1035073725
Summary: This will be used in ephemeral commit, since by default it does not need to include untracked files
Reviewed By: quark-zju
Differential Revision: D27580975
fbshipit-source-id: 16c4faa92e9afe472ff1677e5b92507bebaee247
Summary: The default limit for commit cloud interactive history should be two weeks, not two days.
Reviewed By: farnz
Differential Revision: D27589697
fbshipit-source-id: 4314621fa7f06dac9243eb9b826acc1c7b0c0b10
Summary:
This crashes with `ui.ignorerevnum=1`.
Rev number should use `%d`. Or use node and `%n`. `%s` is not the right way.
Reviewed By: kulshrax
Differential Revision: D27527470
fbshipit-source-id: 115385d8bb8dd006fcbf62dee1099b8f9d5262c7
Summary:
Since we're rolling out native checkout and resumable checkout around
the same time, let's make resumable checkout optional so we can turn it off it
causes issues, without turning off native checkout.
Reviewed By: quark-zju
Differential Revision: D27481986
fbshipit-source-id: a0a3e68567ca2a468e852dce95c03c4b606aaf22
Summary: This makes it easier to use.
Reviewed By: kulshrax
Differential Revision: D27406589
fbshipit-source-id: 11bef407ab620859381c6ee952e6ef00494551e1
Summary:
The issue is that `mut i: usize` is no longer shared across multiple `async
move` blocks (introduced by D27308798 (0df4efa969)).
Rewrite the logic to collect `ids` first, then use `vertex_name_batch`
query instead.
Reviewed By: sfilipco
Differential Revision: D27406586
fbshipit-source-id: b41fe3a13114dc34aa5763e6e2bebe0571decc87
Summary:
Merge paths like `x~n` and `x~(n+1)` to `x~n (batch_size = 2)`.
This could be more efficient bandwidth-wise and algorithm-wise.
Reviewed By: sfilipco
Differential Revision: D27406587
fbshipit-source-id: f2a67352ad627945685e33667e8299a2bc652930
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
