Summary: It's a no-op already. Drop it.
Reviewed By: singhsrb
Differential Revision: D14180595
fbshipit-source-id: 9f904b818bcf56b9d12405ca9894baa9c786801b
Summary:
All commits belong to `default` branch. Therefore `branch(x)` can be seen as
just `all()`, assuming `x` is a valid name.
This removes the only user of `repo.revbranchcache`.
In a later step, branch related features will be moved to an extension so the
code becomes separate and features are optional.
Reviewed By: sfilipco
Differential Revision: D14180594
fbshipit-source-id: 9dc52743f1b69a1838114c8c0de5fc69383dc41e
Summary:
This hardcodes several perftweaks configs that have been enabled for major FB
repos for months:
[perftweaks]
disablebranchcache = True
disablebranchcache2 = True
disableresolvingbranches = True
disableupdatebranchcacheoncommit = True
Practically, this means the branchmap is now just `{'default': heads}`. (i.e.
there are no named branches other than `default`), and branchcache is removed
(i.e. `.hg/cache` does not exist without clindex or in-repo tags).
This diff only makes easy-to-verify logic changes by assuming the configs and
removing dead code. Things can be further cleaned up. They will be done by
upcoming changes.
Most test changes are due to the fact that `.hg/cache` is no longer created.
Reviewed By: singhsrb
Differential Revision: D14179858
fbshipit-source-id: 479f7427168eb1d9614a973e273a229e50f5620a
Summary:
The tests are about HTTP bundle1 support, which is not an environment we care
about. They will break in a way that is non-trivial to fix with the upcoming
branchmap removal. There is little value keeping them. So let's just remove the
tests.
Reviewed By: sfilipco
Differential Revision: D14179859
fbshipit-source-id: 09392bb2e5c0aebc30e584ed3a6593b0b2a81089
Summary:
The WSGI parameter part gets changed with the upcoming branchmap removal.
We don't have resources to maintain WSGI for now, so let's just remove the
test.
Reviewed By: singhsrb
Differential Revision: D14179860
fbshipit-source-id: b2b82f7658a754caece220fa5f80d15514dd9260
Summary:
The CVS branch support will break with the upcoming branchcache removal.
CVS repos are rare. Let's just remove the code.
Differential Revision: D14179863
fbshipit-source-id: 890ce34958d2efe4f2ef02b1d72cf92f6269378c
Summary:
We had `ui.checkheads=false` set for a long time. Let's remove the feature
entirely and update the tests.
This is necessary before killing the branch cache, as some tests still use
different branches and there would be suddently more "heads" that cause
test issues.
Reviewed By: sfilipco
Differential Revision: D14179861
fbshipit-source-id: 0de76566799a9560b45e823cc5f49cfda9e3dd30
Summary:
The checkheads feature is being removed. See D8148016 for details.
This diff just removes tests with "checkheads" in their names.
Reviewed By: sfilipco
Differential Revision: D14179862
fbshipit-source-id: abd5bb26c0d92276273bef7ea93096ca3fde95dc
Summary: Build openssl using vcpkg. Then zip its build results.
Reviewed By: kulshrax
Differential Revision: D14197306
fbshipit-source-id: 7f019f52fb93118cb7c20c95cf41aedf3a1fbefc
Summary:
The purpose of `FileMetadata` is to be a data container. Using the
`FileMetadata` implies accessing the underlying values. That means that the
underlying values need to be `public`.
Differential Revision: D14178260
fbshipit-source-id: 8b8e5ead23d47962498f991152c2a5fd94ac3c74
Summary: These implementations are going to used in quickcheck tests.
Differential Revision: D14178259
fbshipit-source-id: 0bded67deab3422b4aad53666c14cf195ea1b0d4
Summary:
`as_bytes` is useful for interacting with code that is written in reference
to a `slice` or when attempting to serialize them. It is fine to serialize
these paths using their underlying representation because we request that they
be normalized.
Reviewed By: quark-zju
Differential Revision: D14178263
fbshipit-source-id: 36529e2ae47580ae4014ae279df98b35eac5484a
Summary:
Implementing these traits allows easy use of `RepoPath` and friends in
quickcheck tests.
It is tricky to implement `PathComponentBuf`. I believe that most strings will
end up being a valid `PathComponent` so I think that it is reasonable to loop
until a valid string is found. To note generating Arbitrary Unicode `char`s is
implemented using a loop where random bytes are validated against the `char`
constructor.
Reviewed By: quark-zju
Differential Revision: D14178262
fbshipit-source-id: 759486a2053b851f8259d7cc03eee1cd69893f9f
Summary:
These constant can be useful for parsing byte streams that we expect to contain
`Node`s. These constant should replace all potential hardcoding of values that
intend to represent the byte lengths for `Node`.
Differential Revision: D14178261
fbshipit-source-id: 34471151b5d253504e32a9e8b039608c1d4943fe
Summary: Mononoke uses the markers but we shouldn't look at them for Commit Cloud.
Differential Revision: D14188356
fbshipit-source-id: e5dee581728a9bc83d2f7a17575b3ae6b3183d39
Summary:
add this check to avoid overhead
we don't need to backup to the secondary place if it is the same as the first.
Reviewed By: singhsrb
Differential Revision: D14187754
fbshipit-source-id: 6ee59ae2f0846716ca99253958af7088d0538df9
Summary: Just renaming, and another variable as well to look similar
Reviewed By: DurhamG, quark-zju
Differential Revision: D14185033
fbshipit-source-id: e34de690274afd2f2c6e51db21c7b158f6c3452a
Summary:
Instead of using the rand crate imported into quickcheck, we can use the
rand crate directly.
Reviewed By: quark-zju
Differential Revision: D14174653
fbshipit-source-id: c848f139765b9e458d374790227399f0ad836af6
Summary:
The watchman_client crate relied on unix-only crates for both
unix_socket_transport and command_line_transport. Let's not compile
these on windows.
Reviewed By: quark-zju
Differential Revision: D14174654
fbshipit-source-id: 67d26d1799e71a1bf20af1a57a687249f5dce227
Summary: Changing the permission on the packfile failed due to the file being opened.
Reviewed By: quark-zju
Differential Revision: D14174652
fbshipit-source-id: 356ac4748fd69e660a6cb9e63367a87489755e5e
Summary:
Treemanifest uses it's own fallbackpath for reads in all cases, but
particularly in the case of remotenames it should stay on the path that is
actively being used by the push. It is possible to have remotenames which are
mirrored and selected by query strings in the repo path. In this case it is
possible that the mirror is still out of date when reading back data from our
push. Ensure that when doing a push the remote server this is considered
'sticky' so that we read back from the remote we pushed to, rather then
determening the path ourselves.
To disable, please use:
treemanifest.stickypushpath=False
Reviewed By: DurhamG, markbt, quark-zju
Differential Revision: D14165444
fbshipit-source-id: 75a53ffab895d87a4c52814f7887145c134868b5
Summary:
Context: in pushrebase replay job we run on Mononoke we also want to test our
hooks i.e. replay pushrebase requests that were denied on mercurial because of
a hook failure. The problem is that at the moment the only error message we have
is `prepushrebase.driver hook failed` (see xdb table `xdb.mononoke_production`,
query `select * from pushrebaserecording where pushrebase_errmsg like '%hook%'
limit 10;`). This error message tells us nothing, not even what hook failed.
To change it I suggest to make it possible for python hooks to raise HookAbort
and provide more information in the `hook_failure_reason` field.
Reviewed By: quark-zju
Differential Revision: D14131359
fbshipit-source-id: 69a2b51b30c78efadf3ba0d3332f46a777022568
Summary: In chef there is currently an override to 50, so if someone got more due to some reason, it is nice to add a message.
Reviewed By: quark-zju
Differential Revision: D14170749
fbshipit-source-id: 3f3c79e4e6103523c14c8d9c1600f104e3d5d3d8
Summary:
Rust tells us that Rng::choose and Rng::shuffle should be replaced by
SliceRandom::choose and SliceRandom::shuffle, so let's do it.
Reviewed By: singhsrb
Differential Revision: D14178565
fbshipit-source-id: 586eb2891f1c2cab0a3435c1b4ae8f870e7a3c25
Summary:
Tell serde to use an [untagged representation](https://serde.rs/enum-representations.html#untagged) of this enum. This means that `Parents::None` will map to a null value, `Parents::One` will map to an array representing a `Node`, and a `Parents::Two` will map to an array of 2 arrays representing `Node`.
Using CBOR serialization, this means that these variants are 1 byte, 21 bytes, and 43 bytes respectively.
Differential Revision: D14174309
fbshipit-source-id: 0217a23c4ee5409ab293525d7b6e5ae969b5504d
Summary: Add implementations for `FromIterator` and `IntoIterator` for the `Parents` type to make it more ergonomic to use.
Reviewed By: quark-zju
Differential Revision: D14172511
fbshipit-source-id: 5ba848c1dfbb8cc23ed19c9dc816616f5ed7af5f
Summary: Add a convenience function to `MutableHistoryPack` to add an entry from a `PackHistoryEntry` struct.
Differential Revision: D14162781
fbshipit-source-id: a0e07f34b9231011a339ce63adcef8ab55a0555e
Summary:
This changes the way we represent history entries for the Eden API by splitting them into two types and putting them into a new `historyentry` module.
- `PackHistoryEntry` is the same as the old `HistoryEntry`, containing the fields required to add this entry to a `MutableHistoryPack` (namely a `Key` and a `NodeInfo`).
- `LooseHistoryEntry` is a history entry containing the information that would normally be present in a line of the history text in the remotefilelog loose file format.
There are several reasons why it makes sense to have both of these types:
- The existing remotefilelog code in Mononoke uses a type very similar to `LooseHistoryEntry` internally, and as such having a similar type for API calls simplifies code on the server side.
- `PackHistoryEntry` contains redundant information (in particular, the file path may be duplicated up to 3 times). While it's structure is ideal for `revisionstore`'s in-memory data structures, for transmitting data, this redundancy is undesirable, especially since the client already has the file path (it is required to make the request in the first place).
- Conversions between these two representations include some subtle details that are tricky to get right. By putting the conversion in one canonical place, we can avoid having to duplicate this conversion logic in multiple places.
Differential Revision: D14162783
fbshipit-source-id: 63e0a060709916f21613442b75370f4d34a04f04
Summary:
Add a type representing a node's parents. Mercurial nodes can have zero, one, or two parents; this is normally represented as an array of two node hashes, with any absent parents denoted with a null hash. This representation is not particularly Rustic because it allows for invalid combinations (such as a null p1 and non-null p2) to be represented. By using an enum, invalid values are unrepresentable, making code using this type simpler (due to not requiring validation logic).
This type will be used later in the stack to represent parents in history entries.
Reviewed By: quark-zju
Differential Revision: D14162782
fbshipit-source-id: dfff3ecc76dea114e0044839216d080b7f34a506
Summary: `pastry` is the modern replacement for `arc paste`. Let's use it in `hg rage` instead of `arc paste`.
Reviewed By: singhsrb
Differential Revision: D14172108
fbshipit-source-id: 6586b9a8d8b90bac55d91baed852edbc7c1d9db9
Summary:
`Durable` nodes are inner nodes that come from storage. Their contents can be shared between multiple instances of Tree. They are lazily evaluated. Their children list will be read from storage only when it is accessed.
The inner structure of a durable link poses an interesting question related to handling failures: what do we do when we have a failure when reading from storage?
We can cache the failure or we don't cache it. Caching it is mostly fine if we had an error reading from local storage or when deserializing. It is not the best option if our storage is remote and we hit a network blip. On the other hand we would not want to always retry when there is a failure on remote storage, we'd want to have a least an exponential backoff on retries. Long story short is that caching the failure is a reasonable place to start from.
The lazy-init crate is useful for modeling the lazy initialization model that we have for durable node links. See docs at https://docs.rs/lazy-init/0.3.0/lazy_init/
Reviewed By: quark-zju
Differential Revision: D14142928
fbshipit-source-id: 077f708b38e2ace772f30b3392445326ce17f47c
Summary:
The store abstracts the data that we need from the store for TreeManifest. This is not a long term abstraction, mostly something that we can code against until we write the real parsing logic from the real data store.
Adding a TestStore implementation that we can use in tests and debug.
Reviewed By: quark-zju
Differential Revision: D14142930
fbshipit-source-id: 7f2d4f05a7b7e63758db9247cdbcd51541c88ec0
Summary: Preparing to add the store abstraction for the tree manifest. This store implementations are going to be tied to the tree implementation and should be made private from the rest of the crate. To do this we move the tree to a module.
Reviewed By: quark-zju
Differential Revision: D14142929
fbshipit-source-id: 588d597e1248fc2e632c9efe03f08ba3d491e8cd
Summary: manifest::tree::Link has several convenience functions. In the grand scheme of things this is something that we will want because they are common operations. The problems is that the node structure is currently changing rapidly and the additional layer of abstraction is hindering iteration. I don't know the exact shape that the nodes will have and trying different things out is easier when the Tree functions use the nodes directly.
Reviewed By: quark-zju
Differential Revision: D14142926
fbshipit-source-id: 5e4e8f4d3e1b19fd14dcc290a3dea4271b502d97
Summary:
Currently, stackpush requires specifying the original node for each
new node to be created. This inhibits the creation of new commits which are not
replacing any commit via stackpush. This commit changes the behaviour such that
specifying the original node is optional.
Reviewed By: quark-zju
Differential Revision: D14153674
fbshipit-source-id: b3d150a8a8044ac1740937f2dc058ce542ee13e4
Summary:
First stab at a job that will keep hg in sync with Mononoke when Mononoke
becomes a source of truth.
Reviewed By: ikostia
Differential Revision: D14018269
fbshipit-source-id: f88c5eba8bf5482f2f162b7807ca8e41a3b4291d
Summary: There was a typo, the timezone is `[1]` and not at `[0]`
Reviewed By: ikostia
Differential Revision: D14147329
fbshipit-source-id: 8ad4bff810ed949a9f8e86d03ef62bc63aaf11bd
Summary:
Alias documentation can now include multiple lines, however for the output
of `hg help commands`, only the first line should be used.
Reviewed By: quark-zju
Differential Revision: D14149607
fbshipit-source-id: 84992078c9bc4659532350b47694c562f4dc1983
Summary:
Remove:
- log --only-branch
- pull --branch
- push --branch
- record --close-branch
- incoming --branch
- outgoing --branch
Currently, `log --branch` is kept since some arcanist code still uses it.
We can probably remove it after the next arcanist release.
Differential Revision: D14116320
fbshipit-source-id: 50960ae8700200b322f615c4defd9c05353c2435
Summary:
CommandError happens if there is an unknown command flag, or a required
argument is missing. The old behavior is to print an error message to
stderr, then start the pager with the command help printed to stdout.
There are 2 problems with that approach:
1. When using mosh, a long help text might flush the actual error to out of the
screen. The error message will be missed.
2. When captured in shell scripts, the help text printed to stdout would be
captured, which is almost always undesirable.
The actual motivation of this change is for 2. Zsh themes like bullet-train [1]
uses `hg id -b 2>/dev/null` and we'd like to remove `id -b` support. After that,
the command should not polluate stdout with help text.
[1]: bd88ade263/bullet-train.zsh-theme (L102)
Differential Revision: D14151200
fbshipit-source-id: edd38e91115f96929438379aa2e40edfba560b41
Summary:
It's possible that the non-mergedriver code path decides to create ("get") a
file, because it only exists in one side of the merge parents, while
mergedriver decides to remove that file. That makes the file exist in both
"g" (get, aka. create) and "r" (remove) lists and result in incorrect
dirstate state.
Fix it by detecting the case and remove the conflicted files from the "g" list.
Reviewed By: DurhamG
Differential Revision: D14145990
fbshipit-source-id: f4e5d9787dca5cda6cae270f8a84296ecddf553c
Summary:
vipannalla encountered an issue that his mergedriver code does not know the
complete list of files to "driver-resolve" at the "preprocess" step.
When doing "queueremove" files from one-side in the "conclude" step, the
dirstate would have "!" state afterwards.
Add a test to show that.
Reviewed By: DurhamG
Differential Revision: D14145989
fbshipit-source-id: e316aedea3359260dfbf7578a332f87b99fb37f9
Summary: the push-path will be used for Mononoke write path roll out.
Reviewed By: markbt
Differential Revision: D14153207
fbshipit-source-id: 158e6e08dfa017c98e668fdfc37138dd7b7d76c7
Summary:
We can't run in parallel at the moment as the log file and the lock file are
shared.
Every path maintains independent backup state (the previous diff).
The secondary backup state doesn't affect smartlog (only the main one)
The issue with this approach is that we maintain backup lock a bit longer.
Unfortunately, the progress in smartlog doesn't show anything about the second backup.
I added 'finished', it makes it easier to compare in the logs.
Reviewed By: markbt
Differential Revision: D14149399
fbshipit-source-id: f90e8aac6cb8dee53d5c7468bd6adba067e13362
Summary:
We are going to support 2 different backends of Commit Cloud: Mercurial and
Mononoke.
Each of them should maintain local backup state separately.
Output of some tests have been slightly changes, this is because a separate backup
state, the same error appears earlier when we are trying the backup stacks.
The idea is to have separate backup states for different remote paths, but
there will be only one cloud sync state for the current source of
truth. We could include there the remote path and then validate that cloud sync
state is correct if the remote path has been changed.
However, for backup states it is much easier to have them separately (and we
will backup in 2 places)
Reviewed By: markbt
Differential Revision: D14138496
fbshipit-source-id: 0a7a763a395be5456cbd724bff7ebc069f03fb0e
Summary: Add conversions between the `HgFileHistoryEntry` type produced by Mononoke and the `edenapi_types::HistoryEntry` type shared between Mercurial and Mononoke. The latter can be serialized and sent from the API server to the Mercurial client, and will be used for HTTP history fetching.
Reviewed By: quark-zju
Differential Revision: D14079338
fbshipit-source-id: 2123c88310f633f87d8c92405382d5046874dfee
Summary: The `hg update` command has short flags for `--merge` and `--clean`, namely `-m` and `-C`. Let's add the short versions to `hg next` and `hg prev` as well.
Reviewed By: quark-zju
Differential Revision: D14155218
fbshipit-source-id: d51f5f658b525809e4c512ffa300dea4b4cabcdf
Summary:
We're encountering an issue that I think is caused by invalid data
coming back from memcache, possibly due to our recently introduced connection
reusing. Let's add some checksums to verify that the data we put in is identical
to the data we get out for a given key.
Reviewed By: kulshrax
Differential Revision: D14141683
fbshipit-source-id: 206b51b862db7d54def02f5310b90f473d5a0d03
Summary: We weren't passing the `--merge` flag from `hg prev` and `hg next` to the underlying invocation of `hg update`. This diff fixes the problem so that `--merge` now works as expected.
Reviewed By: DurhamG
Differential Revision: D14154244
fbshipit-source-id: 4a2412cca714ec8f269eb5f2989e39821642fbb3
