Summary:
In order to support gradual rollout of infinitepush for other backends (e.g. Mononoke), we need the ability to route read vs write requests separately. To achieve this, we need a separate path type: `infinitepush-write` (kind of like `default-push`, the naming inconsistency is a little unfortunate, as I don't want to use `infinitepush-push`).
The desired behavior of the new path type is as follows:
- takes precedence over `infinitepush` path when the user does `hg push -r . --to scratch/bla`
- replaces `infinitepush` path when the user does `hg push infinitepush -r . --to scratch/bla`
- absence of this path means draft pushes will go to `infinitepush` path
- draft pulls always go to `infinitepush` path, and *there's no fallback to `infinitepush-write`*
- commit cloud always talks to `infinitepush-write`, if it is present (meaning that commit cloud pulls do go to `infinitepush-write` path
- this is done, as commitcloud uses infinitepush paths to also check whether something is backed up
- and also, commitcloud may need to pull very soon after something has been pushed
Reviewed By: quark-zju
Differential Revision: D20368158
fbshipit-source-id: 59db174cebbf2b48765dff37bc93aad176c2d7c1
Summary:
D18538145 introduced a transaction that spans the entire infintepush
pull. This has a couple of unfortunate consequences:
1. hg pull --rebase now aborts the entire pull if the rebase hits a conflict,
since it's unable to commit the transaction.
2. If tree prefetching fails, it aborts the entire pull as well.
Tests seem to work fine if we scope down this lock.
Reviewed By: xavierd
Differential Revision: D20260480
fbshipit-source-id: d84228ababdb5572401645f74e78df035bf1461b
Summary:
Notably, we drop all the encoding business when dealing with json
objects, and instead use mercurial.json.
Reviewed By: sfilipco
Differential Revision: D19888130
fbshipit-source-id: 2101c32833484c37ce4376a61220b1b0afeb175a
Summary: There is no need to open a transaction otherwise.
Reviewed By: DurhamG
Differential Revision: D20109840
fbshipit-source-id: e47adaaeea2d7565f3629701d8de4a67d4b55182
Summary:
These are a random batch of stack traces that show up in remotefilelog
tests.
Reviewed By: quark-zju
Differential Revision: D19772619
fbshipit-source-id: a8b9ce188cb7a5a2c9ccaeb62f6744f1c4083e38
Summary:
Previously we had infinitepush path which was preferred over a default path when a
specific revision was pulled or updated to (i.e. "hg pull" would use
paths.default, but "hg pull -r HASH" would use paths.infinitepush if this path
is set in the config).
I'd like to have infinitepushbookmark path which will be preferred for all
cases except for a single commit pulls.
Reviewed By: mitrandir77
Differential Revision: D19513490
fbshipit-source-id: 7f8b809f937aa2e082c2e9cd382709c6db619a4f
Summary:
Previously the mutation commit extras were the source of truth for mutation
information, and the mutation store served as a kind of cache. This turned out
to be less useful than expected, as oftentimes commits are missing, and the
store is better indexed, so in practice using the store as the source of truth
is better.
This change makes the mutationstore the (sole) source of truth for mutation
data. The extras are kept, but they are now only useful as human-readable
debug information, and to ensure the commit hash is unique.
Collecting the mutation information during commit creation is now done through
a new `mutinfo` object. This is a dict with the same keys as the mutation
extras, for simplicity, but it is now passed through the `committablectx` and
used to generate the mutation store entry directly.
The `mutation.enabled` config option is now used to control all aspects of
enabling mutation.
The `mutation.record` config option is now only used to indicate whether the
mutation extras should also added to the commit. Generally this should be set
to `true`, however the option is retained so that mutation extras can be
stripped by running `hg amend --config mutation.record=false`, which no longer
has the side-effect of not recording mutation information to the store.
The "remote commit" mutation record origin is now obsolete, and won't be
generated anymore.
Pushrebase now relies on the obsmarker information coming back from the server
in order to correctly generate mutation information. We will need to change
this so that the server returns mutation records before we can fully deprecate
obsmarkers.
Reviewed By: DurhamG
Differential Revision: D19410650
fbshipit-source-id: 8d7094e4bfd8d8e97916898d899a8debd339485f
Summary:
See also D5271419. Decorators in `bundle2` and `exchange` are not side-effect
free. Move them to `uisetup` for better chg compatibility.
Reviewed By: StanislavGlebik
Differential Revision: D18926782
fbshipit-source-id: b99e2882cb6530a648a065c6d739ee9a7aebb851
Summary: This resolves ProgrammingErrors detected by a later change.
Reviewed By: xavierd
Differential Revision: D18538145
fbshipit-source-id: 650e956707af6024457cdc7dabf516d087ad03cd
Summary:
In preparation for merging fb-mercurial sources to the Eden repository,
move everything from the top-level directory into an `eden/scm`
subdirectory.
