Summary: The hg pasterage is the command that people run to share debug info when something is wrong with their repository. Having the information about CommitCloud related stuff will help with all the future debugging of that.
Reviewed By: mitrandir77
Differential Revision: D15744065
fbshipit-source-id: 094ccdf79c38fed78f5106a1617a5af09e1870e8
Summary: The `osutil` module is re-exported by `util`. Use `util` instead.
Reviewed By: xavierd
Differential Revision: D15798643
fbshipit-source-id: 3b5ec4ce737664d70859889b1aaa18d09c2feb19
Summary:
The multiplexing has been on for hg_dev hosts for a while, with no issues,
let's use it exclusively when the indexedlogdatastore config is set.
Reviewed By: kulshrax
Differential Revision: D15763914
fbshipit-source-id: 9d33c215f700c57bf3cf0d8e55117b1020bb422a
Summary:
We've had this on for the hg_dev servers for a while, with no notable issues.
Let's move it out of the experimental folder.
Reviewed By: kulshrax
Differential Revision: D15763915
fbshipit-source-id: ff1059d0b77fd8b564f4d02753606f2800146949
Summary:
Let's avoid the copy/paste of code. This will also allow to move it out of the
experimental path more easily.
Reviewed By: kulshrax
Differential Revision: D15763917
fbshipit-source-id: 4f61bfa8562cdd836d61efc96c180908f07ea74f
Summary: This adds (behing a feature flag) the option for Mercurial servers to record bundles they ingest into a `forwardfillerqueue`. This queue is consumed by the commit cloud forwardfiller (see stack rooted at D15712911 for that) to replay those commits into Mononoke.
Reviewed By: farnz
Differential Revision: D15759638
fbshipit-source-id: 70660343408bbaa865fc8f51f49f590eaf525cce
Summary:
With listserverbookmarks in hg, we have to wait for an hg release to be able to run our monitoring, which isn't ideal.
Furthermore, the listserverbookmarks method command is unlikely to be used by anyone else, so we might as well provide it directly for review-bookmarks (like we do in e.g. the commit cloud backfiller for, though if we change our minds later we can always just revert this diff and the corresponding fbpkg change).
Reviewed By: farnz
Differential Revision: D15778340
fbshipit-source-id: d8fd6c9e1d33a420f95bdb4fadb582b864c51d5f
Summary:
After asking hg_memcache_client to fetch some data, we need to refresh the
underlying store. This refresh needs to be done after hg_memcache_client wrote
to it, not after we do the request.
Reviewed By: quark-zju
Differential Revision: D15763916
fbshipit-source-id: 99e88ffa13dba4394344c9340eba3f12fcfe0b76
Summary:
This adds a listserverbookmarks command to list bookmarks at a path without a
repository.
Reviewed By: ikostia
Differential Revision: D15737661
fbshipit-source-id: e2cd5dbcfe5c24868dd1d2b6685ebe13b1762676
Summary: Update the messages in the debug output for HTTP data fetching to specify whether we're downloading file content or file history.
Reviewed By: xavierd
Differential Revision: D15749426
fbshipit-source-id: e6fdff87d2cdc439549773c85a83341650652755
Summary: Print out download stats for HTTP tree fetching when `edenapi.debug` is set.
Reviewed By: xavierd
Differential Revision: D15746069
fbshipit-source-id: ab7f5bc67f4af64116a3095dd4424cfef9198f80
Summary:
In order to not have to deal with linkrev in mutablehistorypack, let's split
_addtopack in 2. This will allow _addtreeentry to be wrapped later to deal with
linkrev.
Reviewed By: kulshrax
Differential Revision: D15684625
fbshipit-source-id: 772ffa25ce7b72f95f057d0ae00c89c7dc91bf18
Summary:
Selective pull, when just enabled, will filter only remote bookmark for the active remote repo at that time. When user will try to pull next time from the different remote, bookmarks for that remote won't be filtered, because the selective pull will think that it's already enabled and the remotenames file already has only interesting bookmarks.
I changed `selectivepullenabled` file to keep track of the remotes which selectivepull has been enabled for.
Reviewed By: markbt
Differential Revision: D15583506
fbshipit-source-id: dec09baf1e1a0c80d1d5987ac6f85fe1202b2dab
Summary: Now slective pull, when enabled, will keep not only configured remote bookmarks, but accessed, that were recoreded earlier, as well.
Reviewed By: markbt
Differential Revision: D15583505
fbshipit-source-id: 8c8d300afc333a94427513d9844c1c1af3cf7f32
Summary:
If selective pull is enabled, the old implementation of `--remote` doesn't show all available remote bookmarks, but only locally available ones.
New implementation uses `listkeys` API to fetch remote bookmarks from the server.
However because `remote-path` flag belongs to the infinitepush extension, if the extension is not enabled, than `--remote` will show only bookmarks from the default remote.
Reviewed By: markbt
Differential Revision: D15547513
fbshipit-source-id: b7c79a0cc7237bbf086c64a71d6ed313aa520582
Summary:
With selective pull feature we need to have ability to list locally available remote bookmarks - the bookmarks the user is subscribed to.
As current implementation of `--remote` does exactly that, pointing subscription to the same implementation.
Reviewed By: markbt
Differential Revision: D15547515
fbshipit-source-id: d3ac7295fee3391076855fbe1bed00124dab973f
Summary: When selective pull will be enabled, `hg log` won't be able to show any information about the remote bookmarks that are not in subscriptions for particular user. So we need to hint the user that they may want to explicitly pull the remote bookmark first, if hg log fails to find it.
Reviewed By: quark-zju
Differential Revision: D15516462
fbshipit-source-id: 5be77b0048d8e175a737f76a8e89768f4c837f60
Summary:
As we're working towards moving exclusively to Rust based mutable stores, let's
modify the existing datapack unit tests to test them.
Reviewed By: kulshrax
Differential Revision: D15673688
fbshipit-source-id: 847ec0f5f5316e6f8ba72f27a7665dd3bf46c5fc
Summary: Now that EdenAPI's methods take in a MutableDeltaStore to perform writes, EdenAPI no longer needs to know about the cache path, as this is an implementation detail of the store. This field was no longer used anywhere (except by the constructor code which created the cache directory if it didn't exist -- this behavior is now handled by the MutableDeltaStore), so let's remove it.
Reviewed By: quark-zju
Differential Revision: D15715777
fbshipit-source-id: 11908c6be49f8846e1b7ba5890200d08529441e8
Summary: Add a new command, `hg debugserialgetfiles`, which works just like `hg debuggetfiles` except that each file is fetched serially via a separate call to `edneapi`'s `get_files` method. This is designed to simulate a pathological case where Mercurial performs a series of individual file fetches, depriving the Eden API client of the opportunity to use batching, etc. In particular, this command is intended to be used to test TCP connection reuse inside of libcurl.
Reviewed By: quark-zju
Differential Revision: D15707993
fbshipit-source-id: d57550639839ed597347228059f51ed343151867
Summary: Use a formatting function to pretty print byte counts in progress bars for HTTP data fetching. Also correctly pluralize the progress bar message. (i.e., treat "1 file" as a special case.)
Reviewed By: quark-zju
Differential Revision: D15700946
fbshipit-source-id: d2baaa757787ebeeb94d4b987128d8fafd12f19b
Summary: This diff adds a new `treemanifest.usehttp` config option. When set, Mercurial will attempt to prefetch trees from the API server, falling back to SSH if HTTP fetching fails.
Reviewed By: markbt
Differential Revision: D15506807
fbshipit-source-id: a5c5fcf14f29aee083c9fa0daeb0aedb5c1ec9a9
Summary: D13838772 introduce validation of hashes when fetching data from mercurial/memcache. We'd like to get insights in to how often this would happen, and potentially attach alarms to notify.
Differential Revision: D15472456
fbshipit-source-id: ad2f28e91824e4bbfc02284f230111e2d4cb3f00
Summary:
The clients don't have any mapping from `globalrev->hash` locally but
they can do this lookup quickly using ScmQuery. We do not want to invest too
much effort on supporting globalrev based lookups on the clients as this is a
workflow we want to discourage anyway. But, for now, existing workflows may
break if this lookup is slow on the clients. Therefore, for the interim, lets
just have this lookup backed by ScmQuery. We can later improve or completely
discard this based on the future direction for globalrevs.
Reviewed By: quark-zju
Differential Revision: D15588420
fbshipit-source-id: 61f91414248ca1defe6eac4311243ee8029a92cf
Summary:
We will eventually get rid of the `hgsubversion` extension and
therefore, we want to remove any dependency on it in the long term. This commit
removes any dependency on the `hgsubversion` extension for resolving the revset
string corresponding to the globalrev.
Reviewed By: quark-zju
Differential Revision: D15586218
fbshipit-source-id: 79685ce96075a162d40ce2ce48d347333d768d7a
Summary:
Support bundlerepos with mutation data.
Infinitepush is currently the only place where bundles may include mutation
data. This is used when rebundling infinitepush bundles to send back to the
client.
Reviewed By: mitrandir77
Differential Revision: D15604475
fbshipit-source-id: 111a3211044c742d3d1c75d06c6e6114f754e396
Summary:
The tempfile crate creates temporary files with the mode 0600 and thus when one
is persisted, it keeps these permissions. This effectively prevents a shared
indexedlog to be used by anybody but the owner.
Reviewed By: quark-zju
Differential Revision: D15580364
fbshipit-source-id: 06ca3872287b618bfbab28327644a143db7282c9
Summary:
Update `hg githelp -- git branch -d` suggestions to suggest `hg hide -B`.
Also fix up the code so that trailing `-B` options are not produced.
Reviewed By: farnz
Differential Revision: D15575864
fbshipit-source-id: bd0d0b23f2a509e02554bcbb453718bebe8ea11a
Summary:
Add support for `hg hide -B bookmarkname`. This hides all commits that are
uniquely reachable by the provided bookmarks. This means if a bookmark is at
the head of a stack, `hg hide -B bookmark` will hide the stack.
Reviewed By: quark-zju
Differential Revision: D15562715
fbshipit-source-id: 9fdb3383b534faea982396a4f4782c03e4910dc3
Summary:
Make the code for calculating which revisions the `-B` options to `hg prune`
and `hg debugstrip` affect common to both commands.
The remotenames modification of `repair.stripbmrevset` is wrong. It should
exclude all ancestors of commits that have remotenames, not just those that
don't share a bookmark with the remotename. Fix it.
Reviewed By: quark-zju
Differential Revision: D15562716
fbshipit-source-id: 507002505100e7d60c395f242cc8e1062b91cc20
Summary:
Update all rust crates that compile on Rust 2018 to use the 2018 edition.
The `commitcloudsubscriber` crate only compiles with Rust 2015, so make that
explicit in `Cargo.toml`.
Reviewed By: farnz
Differential Revision: D15601648
fbshipit-source-id: 7380e6e695fc3049913af91fcbde105dfe1be4bc
Summary:
This will allow us to efficiently identify scratch pushes that are not properly being pushed to both Mercurial and Mononoke.
When we roll out `infinitepush-other`, this will be helpful to make sure all repositories are properly configured to push to both destinations.
Reviewed By: farnz
Differential Revision: D15577201
fbshipit-source-id: 17912b90a934f65ed21851170402ae498b127c14
Summary:
Through Scuba, we can identify quite a few users that are doing `hg push default` for an infinitepush: https://fburl.com/scuba/6vz3ien7.
This is typically happening in repositories where the `default-push` destination is not the hg repository.
In fact, we actually prompt users to use hg push default if they try to perform a scratch push to a svn repository a few lines below!
markbt suggested we should just replicate the push in this case as well, which I think is a good idea.
Simply replicating the push in this case is not quite enough, however!
Indeed, for our infinitepushes to go to both Mercurial and Mononoke, we would have to maintain an number of consistency rules between `default`, `infinitepush`, and `infinitepush-other`:
- `default` and `infinitepush-other` must point to opposite repositories (i.e. one Mercurial, one Mononoke), to serve users using `hg push default`.
- `infinitepush` and `infinitepush-other` must point to opposite repositories, to serve users using `hg push` without a path.
This effectively means `default` and `infinitepush` must be the same, and `infinitepush-other` must be the other. We could do this with path markers, but this is getting so complicated that I don't foresee us getting it right.
At the end of the day, the root cause of this complexity stems from the fact that we're using a destination that is now effectively a read path (`default`) for infinitepush writes. I think this was perfectly valid when default meant "Mercurial, not subversion", but not so much now that we have Mononoke in the mix.
Of course, we could just update the message and ask our users to use `hg push infinitepush` instead, but this would mess with their muscle memory as well as their shell history (not to mention that `hg push default` would silently do the wrong thing).
So, this patch updates the code to use the infinitepush "write" destination for writes when that is what the user intended.
---
As a side note, note that the current behavior is actually a little broken. Indeed, if one were to do `hg push default --to scratch/$FOO` while Mononoke is serving reads, the scratch would go to Mononoke. In this scenario, the scratch push would in theory have been accepted but would have had its bookmarks discarded (at least until we support htose in Mononoke :) ).
This probably never happened in practice, however, for two reasons:
- Most users and systems that actively push scratch bookmarks are actually pushing to a specific `hg.vip` path instead of `default` (one notable exception is On Demand WWW).
- `hg push` to Mononoke for a scratch bookmark doesn't actually work if you have the pushrebase extension code loaded in some way (either by enabling the extension, or enabling an extension that uses it). See D15576199 for the details.
Reviewed By: farnz
Differential Revision: D15576545
fbshipit-source-id: c28b808632505bb8e8f4d114029f7d8c17c9749e
Summary:
We will eventually get rid of the `hgsubversion` extension and
therefore, we want to remove any dependency on it in the long term. This commit
removes any dependency on the `hgsubversion` extension for retrieving the
`globalrev` corresponding to a commit. Note that the `globalrev` for the older
commits is just the `svnrev`.
Reviewed By: quark-zju
Differential Revision: D15579401
fbshipit-source-id: 021e6d93d008b07591e1b7801062d9c5fbfc7651
Summary:
Infinitepush is not a pushrebase, so we should not send the b2x:commonheads part when we do an infinitepush.
Mercurial doesn't actually care about this, but Mononoke does (because it peeks at the stream to know if we're dealing with a pushrebase or a regular push).
Reviewed By: ikostia
Differential Revision: D15576199
fbshipit-source-id: a90adb5884b00ad65208697fa17983535aacb9c6
Summary:
In D15468485 calls to read the backup state started taking the repo lock to
ensure a consistent state. This had the unintended side-effect of making
revset predicates like `backedup` take the lock on what would normally be a
read-only path.
It's only necessary that sync and backup get a consistent view - it's ok if
logging functions see a slightly stale view of the repo. Move the lock out of
the `BackupState` constructor to the places it is called in sync and backup.
Reviewed By: mitrandir77
Differential Revision: D15575458
fbshipit-source-id: c4f2a62839e5f22a64ff6d6a4e78ef4c65cb8b15
Summary:
This commit just introduces a method for retrieving a mirrored
revision using the relevant ScmQuery API. The eventual objective is to use this
method to also be able to get the `hash` corresponding to a `globalrev` on the
Mercurial clients.
Reviewed By: quark-zju
Differential Revision: D15571470
fbshipit-source-id: cc0506356d27450594a690aa29a2a2a608aac5c0
Summary:
The former will always succeed on Windows, while the later raise an Exception
when the file is opened elsewhere.
Reviewed By: quark-zju
Differential Revision: D15571023
fbshipit-source-id: b7ee739dce49f9a9ba5087ec785a6dc332eb88c8
Summary:
On Windows, keeping the files open prevent them from being deleted.
Make sure we close them temporary packfiles on abort so they can be
removed properly.
Differential Revision: D15550431
fbshipit-source-id: eca557ffd852ef0255fe991c50ce35a6a8ee7fa0
Summary: This updates `hg push` to replicate pushes to the `infinitepush-other` path. This ensures that we replicate pushes to scratch branches to Mononoke once we enable this mechanism.
Reviewed By: markbt
Differential Revision: D15538790
fbshipit-source-id: 0baa31f26f516cf5d2f6ec5a14d8006c912766c2
Summary:
When writing a blackbox log entry, only include the current commit if the repo
has already loaded the changelog. Otherwise, finding out what the current
commit is will load the changelog, which is wasteful, and may cause a
re-entrant call back into blackbox logging.
Reviewed By: xavierd
Differential Revision: D15539413
fbshipit-source-id: 48c27b053b9db7ce5c2d4b1991020adaea720c21
Summary:
When computing which of the lastsyncstate heads should be available in the repo,
use the omittedheads from the lastsyncstate, not the new omitted heads.
Reviewed By: mitrandir77
Differential Revision: D15535780
fbshipit-source-id: 215f037215b20d1188999abfa42e7a45391b7723
Summary:
We have seen reports of this file getting corrupt on Windows when
peoples' machines are hard-rebooted. Handle that corruption with a
more helpful error message.
Reviewed By: quark-zju
Differential Revision: D15506345
fbshipit-source-id: 66d998a156bc11953b5afb440270ff77af4677fc
Summary:
The Rust code doesn't have a close method, but it has a flush one. This has the
drawback of removing the ledger argument from the close method which is used to
guarantee that data gets into the packfile before the rename operation.
For now, let's always sync the file content before closing the mutable
packfile.
Reviewed By: kulshrax
Differential Revision: D15504680
fbshipit-source-id: 09dbda8820351b128038d6c3ea1843fef9c5bc48
Summary:
By using a wrapper over them, it becomes easier to switch the underlying
implementation to be a Rust one.
Reviewed By: kulshrax
Differential Revision: D15504679
fbshipit-source-id: ac87311e015bd4c3baafb8e8e77ab6ed4890cdcc
Summary:
We have to use globs in tests everywhere they output durations. It's
annoying when you have to update many tests, so let's force the output to 0 when
in tests.
Reviewed By: quark-zju
Differential Revision: D15382069
fbshipit-source-id: eaed82e2ba685d594267433494d98fce5de3663e
Summary:
Now that all our repos are treemanifest, let's enable the extension by
default in tests. Once we're certain no one needs it in production we'll also
make it the default in core Mercurial.
This diff includes a minor fix in treemanifest to be aware of always-enabled
extensions. It won't matter until we actually add treemanifest to the list of
default enabled extensions, but I caught this while testing things.
Reviewed By: ikostia
Differential Revision: D15030253
fbshipit-source-id: d8361f915928b6ad90665e6ed330c1df5c8d8d86
Summary:
Cloud sync backs up commits before it takes the lock. If, during this backup
process, another transaction adds new commits to the repository, the cloud sync
process will not be able to sync properly, as some of the commits won't have
been backed up.
Furthermore, because the backup state may have been updated between opening the
changelog and reading the backup state, which means the backup state may
reference commits that are not available in the changelog to the current
process.
Serialize these operations by:
* Reading the backup state file under the repo lock. This, unfortunately, means
`hg cloud backup` needs to take the lock, but it should only be for a very
brief period while a file is read.
* When cloud sync has completed the backup and is about to start syncing, check
that the repository hasn't changed while the backup was running. If it has,
abandon this sync attempt. Another background sync will have been scheduled
that will backup the new commits and then sync everything.
Reviewed By: quark-zju
Differential Revision: D15468485
fbshipit-source-id: 706ada05dfb1f539638104722a044493c7e3e62f
Summary:
Ensure cloud sync gets a consistent view of the repository, and that the sync
operation is a single update, by taking in the lock and using a transaction for
the whole cloud sync.
The commits are backed up before we take the lock, so for syncs that don't pull
in any new commits, this should still be relatively fast: we will only have the
lock for the duration of the request to the commit cloud service. In the case
that we do need to pull new commits, we were already taking the lock anyway.
Reviewed By: quark-zju
Differential Revision: D15468487
fbshipit-source-id: 37abeac85dad8d2cfb4ad160c5f417dde087d74c
Summary:
If a ui object is not available, then callers can't make blackbox logs. However,
the blackbox extension has `lastui()` which lets it find a ui object.
Add `util.log`, a hook point for blackbox that lets callers log to blackbox without
having a ui object to hand.
Reviewed By: quark-zju
Differential Revision: D15495215
fbshipit-source-id: b468647ccacc6992f71b9a8be2552db860d16ebe
Summary: Use `util.timer` to time commands, to make these times stable in tests.
Reviewed By: quark-zju
Differential Revision: D15468482
fbshipit-source-id: 7d15d725ba436915dff5da514398514dd0b113f7
Summary:
This extention will return 0 if the bookmark points to an expected hash and
non-0 otherwise. We plan to use it in Mononoke.
Reviewed By: StanislavGlebik
Differential Revision: D15450801
fbshipit-source-id: 36d938fb6912046ada229a4e35b76e9cf13f0a74
Summary:
Now that all our repos are treeonly, let's default the extension to
using treeonly. This opens the doors for moving all the tests to operating on
treeonly repos in a future diff.
Reviewed By: quark-zju
Differential Revision: D15030251
fbshipit-source-id: cd289775174bbacd6a6cdc7a5b07fe7e41238584
Summary:
Previously readfast was an optimization that sometimes returned a delta
against p1, but other times returned the full manifest. This was weird and
caused certain algorithms to sometimes be O(changes) but other times O(repo).
In a tree world we no longer need this optimization, so let's drop it.
readdelta is similar in that it would read the difference between a manifest and
it's delta base. This has no relationship to the delta between a manifest and
it's parent, so it's weird and we should get rid of it.
There is a legitimate use case for wanting to know what entries are new in a
manifest, like when deciding what to send over the wire. So let's add a new
readnew() function that is explicitly for reading what entries were introduced
by this tree. The implementation is basically the same as readdelta, but
deltaing against p1 instead of the deltabase.
Reviewed By: markbt
Differential Revision: D15344434
fbshipit-source-id: dc8dca326f66b2fc55cc76f93c7ce48aa7efedf3
Summary:
This makes it easier for a wrapping job to associate output with a given command it ran.
Note that creating a SSH peer creates its own copy of the `ui` object, which is why we have to push a buffer to both `ui` instances.
Reviewed By: ikostia
Differential Revision: D15468456
fbshipit-source-id: c6f1937749447e27332801577538d9874eb18898
Summary: Add progress bars to remotefilelog's debug commands for HTTP data fetching. This makes it obvious whether there is activity occurring or whether Mercurial is stuck.
Reviewed By: quark-zju
Differential Revision: D15480683
fbshipit-source-id: 8c67c306488e5ec82a32143eb1748879474e3ec9
Summary:
While mutable datapack are used in several places, most of the writes are
coming through the pendingmutablepack class, so let's start switching these
to use the Rust code.
Reviewed By: kulshrax
Differential Revision: D15482770
fbshipit-source-id: d0e4aae38a5ef2ba625a40ff907420623e6efd11
Summary:
Both the Rust and Python mutable stores support a flush method, but while
Python support an abort method, Rust will simply cleanup temporary files when
the object is destroyed. We can implement a similar scheme in Python by
implementing __del__.
Reviewed By: kulshrax
Differential Revision: D15482771
fbshipit-source-id: 4c9647ab7dd9fa078a8fc3c8b00962fbc0823dfd
Summary:
Opening all the revlogs to validate them is showing up as a performance
bottleneck for hgsql transactions. Let's switch them to using mmap to avoid
reading a bunch of data from disk.
Actually making this have an effect on our servers will also require setting the
experimental.mmapindexthreshold config.
Reviewed By: quark-zju
Differential Revision: D15441867
fbshipit-source-id: 4edde0bc3419ef75f82a4234c9dfc6604c6db9f4
Summary: Print out download stats when `edenapi.debug` is set. Pretty printing of the stats has been improved to make these numbers more useful to humans.
Reviewed By: xavierd
Differential Revision: D15466702
fbshipit-source-id: 6fac9ca5976b98874fc7a5f9b89d42975e1520ce
Summary:
When EdenAPI encounters an error, the current behavior is to print an error message and then fall back to SSH. In addition to the fallback notice, we were previously printing the exception message using `ui.develwarn`, with the understanding that this information is only really useful to Mercurial developers.
Instead of using `develwarn`, let's use `ui.warn` but gate the call so that only users with `edenapi.debug` set to `True` see the error message.
I initially tried printing the entire backtrace with `ui.traceback`, but this proved too verbose to print out in the middle of normal command output. The full traceback is logged to Scuba, and can be obtained from the `hg_errors` Scuba table, so just logging the exception message should be sufficient.
Reviewed By: quark-zju
Differential Revision: D15466332
fbshipit-source-id: 43d40eff47e4f68fe860383e7bd519fbd0052830
Summary: On the Source Control team, we've been referring to the project to replace parts of the Mercurial wire protocol with the Mononoke API server as "HTTP data fetching". This has caused confusion for other teams in the past (particularly teams with a security-related focus), as this nomenclature makes it seem as if we're using unsecured HTTP. (This is not true; we are always using HTTPS.) In light of this, let's make sure that user-facing messages always use the term "HTTPS" instead of "HTTP" to avoid this confusion.
Reviewed By: quark-zju
Differential Revision: D15465390
fbshipit-source-id: b556ed222dc01979ceaa0d4a7aa921cb1c38d75e
Summary: Log metrics about HTTP data fetching to `dev_command_timers`, and log HTTP fetching errors to `hg_errors`.
Reviewed By: quark-zju
Differential Revision: D15464791
fbshipit-source-id: 1027383b6aa0dc6915351332bfbc2d20d540cc4e
Summary: Check that the user's configured TLS credentials exist during client setup and disable HTTP if they aren't present.
Reviewed By: quark-zju
Differential Revision: D15459917
fbshipit-source-id: f20664c6522e47f2960cec1f02ef1a5f4c7e2c8c
Summary: Add several methods to the DownloadStats FFI wrapper to allow Python code to easily access various metrics.
Reviewed By: xavierd
Differential Revision: D15458802
fbshipit-source-id: 9e19d2a9b3fcb6e3a066f040fd110510a2f0d63e
Summary: Make all of the EdenAPI data fetching methods return an object containing metrics. These can then be logged by the Python code.
Reviewed By: xavierd
Differential Revision: D15440641
fbshipit-source-id: 4a5fd090066a9020ae32986ab45ee8fb70c8de53
Summary:
Previously we sorted the trees topologically before inserting them. On
a revlog-backed server, this may mean that trees are written in a different
order from the actual commits. hgsql-backed servers rely on the data being
written in linkrev order so they can be replayed in linkrev order on other
machines, so this broke hgsql replication.
Let's instead sort by linkrev, which will be both topological and satisfy
hgsql's requirements.
Reviewed By: quark-zju
Differential Revision: D15437953
fbshipit-source-id: d4aaaa03b392a6cb6cf1be478aed2583ecb757c5
Summary:
We had this disabled in a config we ship in rpms, but if we want the
tests to work in treeonly mode we want this disabled in all tree cases.
Reviewed By: xavierd
Differential Revision: D15296199
fbshipit-source-id: 0f9751583eefa10c275bd499bb5998adfbe644a4
Summary:
`hg pushbackup` and `hg isbackedup` can be called from scripts with `HGPLAIN`
set, and so can't be provided by aliases. Instead, provide deprecated wrapper
commands.
Reviewed By: mitrandir77
Differential Revision: D15436286
fbshipit-source-id: 3fbbf9a5fb4d0e8de2026a17c41ee11a139d645f
Summary: Improve debugability of cloud sync by logging updated sync state to the blackbox logs.
Reviewed By: mitrandir77
Differential Revision: D15434890
fbshipit-source-id: c5065455985a48777a855997a99e32ce0b31cc72
Summary:
When syncing, if a locally-available bookmark is synced to a new commit that
has been omitted, remove the local bookmark to ensure that the next cloud sync
doesn't move the bookmark back to where it used to be.
Reviewed By: mitrandir77
Differential Revision: D15414172
fbshipit-source-id: 71aaa2d89f734e4c575c24da2c0ef6b59ca4deaa
Summary:
A new flush method is added to mutablebasepack that just close and re-init
self.
Reviewed By: kulshrax
Differential Revision: D15416708
fbshipit-source-id: 79cdcb20b51b9688a5e95402057c7da27883003c
Summary:
This hook fires for every commit that is introduced in a pull. When
doing pulls with hundreds of thousands of commits, this introduces a noticable
delay. We don't use this hook anywhere, and it's not particularly scalable, so
let's delete it.
Reviewed By: singhsrb
Differential Revision: D15424697
fbshipit-source-id: 98d76bca703e625adf5be8f6234436befd260fc4
Summary:
Let's move hgsubversion to absolute_import, just to be consistent with the rest
of Mercurial codebase.
Reviewed By: markbt
Differential Revision: D15392154
fbshipit-source-id: e4c32939aff0616790828da508f3feea158669e1
Summary: As of D15154509, the data fetching functions in remotefilelog write to shared mutable packs rather than opening new packs. As such, there is no need to return pack paths. In fact, the code has already been updated so that the returned paths are always `None`, so the code removed in this diff is already dead.
Reviewed By: xavierd
Differential Revision: D15419765
fbshipit-source-id: c999d5388042b429a8bda9f72a06569364d8e2e1
Summary: This diff adds an `hg debuggettrees` command that downloads trees from the API server and stores them in a datapack.
Reviewed By: xavierd
Differential Revision: D15301607
fbshipit-source-id: 7820d82d7d021c420e911a6a2e9bfce62b69fa2e
Summary:
Improve logging of background backup commands by including the command that was
run and the time it was started in the background backup logs.
Reviewed By: mitrandir77
Differential Revision: D15334879
fbshipit-source-id: 932e91a43033c5cb06c79ede7b5224da2e34eb7d
Summary:
When pulling heads from commit cloud during sync, pull them in small groups
of heads from around the same time, to prevent overloading the server when
pulling a large number of heads.
Reviewed By: mitrandir77
Differential Revision: D15317184
fbshipit-source-id: 5e69eb970b18292a4f5d643b25fac80c90c5d537
Summary:
Lift determination of the correct remote path to connect to up to the top-level
command. This prevents the need to pass around the command-line `**opts` in
all of the commit cloud functions.
Differential Revision: D15295811
fbshipit-source-id: 0e14c1643bad96022c7a01126b447b2a6fcabaed
Summary:
Refactor how commit cloud sync works.
Sync is simplified by delegating backup processing to the existing backup code.
This happens first, which means the user's work is backed up earlier, and the
sync processing can assume that all backed up commits are available in the
cloud storage.
Sync no longer attempts to handle the case where cloud storage has changed.
Instead, backup processing should ensure that all local commits are backed up
to the current cloud storage.
If a commit can't be backed up, then treat this as a normal failure to
sync and ignore that commit for this sync attempt. If a commit can't be
downloaded from the server then the sync fails.
Reviewed By: mitrandir77
Differential Revision: D15295499
fbshipit-source-id: d371c5bf0daedbbe42e8c7d4a0c3d1a40c21a36f
Summary:
Move token location into the `token` module.
Move subscription management into the `subscription` module.
Move obsmarker management into the `obsmarkers` module.
Move everything else to a `util` module which can be disambiguated at import time.
Differential Revision: D15282859
fbshipit-source-id: 7f20c449fd79ffc33b069236a05fc73fac0e7d63
Summary:
The name is too long. We can disambiguate with `edenscm.mercurial.commands` at
import time if required.
Differential Revision: D15282860
fbshipit-source-id: e55357a121b583d9fd659f27dd5e2adc8a3d4d2f
Summary:
Merge the functionality of the infinitepushbackup extension (backing up commits
to commit cloud) into the commitcloud extension.
These two extensions are highly coupled, and the commitcloud extension
monkey-patches the infinitepushbackup extension for a lot of its functionality.
There is also a lot of code duplication between the two extensions which we can
remove if they are part of the same extension.
The infinitepushbackup commands (`hg pushbackup`, ...) are moved to subcommands
of the `hg cloud` command, e.g. `hg cloud backup`.
Each feature of the infinitepushbackup extension is moved to a new module
in the commit cloud extension:
The `background` module controls background execution of `hg cloud backup` and
`hg cloud sync`.
The `backupbookmarks` module tracks and updates scratch bookmarks for backups.
This will be deprecated in the future.
The `backupstate` module tracks whether or not a commit has been backed up.
This is now tracked separately from backup bookmarks in a new file:
`.hg/commitcloud/backedupheads.<remote-identifier>`. This also covers hidden
commits, preventing a re-backup of previously backed up commits when they are
unhidden.
Previously the commitcloud extension customized the smartlog annotations: `Backing up`
became `Syncing`, etc. This is now removed for consistency.
Previously the infinitepushbackup extension disabled background backup by
injecting an `infinitepushbackup.disableduntil` config entry into the user's
config. This is now replaced with a state file at `.hg/commitcloud/autobackup`.
Either option can be set to disable auto backup. Commit cloud will wait until
both have expired before starting to run background backups again.
Reviewed By: DurhamG
Differential Revision: D15276939
fbshipit-source-id: 1d28989a157286e47d3dd97ca9c70b27f692dda1
Summary:
Thin lto is much faster to compile, and doesn't make the resulting binaries
that much bigger.
Reviewed By: xavierd
Differential Revision: D15396282
fbshipit-source-id: 3e2bf059756d47218061d7e41f041e445d7f60c8
Summary:
D15381038 made the `pyrevisionstore` crate a strongly-coupled dependency of the
`bindings` crate. For simplicity, just move the code into the bindings crate.
Reviewed By: xavierd
Differential Revision: D15392547
fbshipit-source-id: 3dfa924b33722760ef7829fbb8659ce0262e6671
Summary:
After D15266191, the bindings crate directly depends on pyrevisionstore, and
since then we have seen really weird compilation errors that magically go away
when some files are touched.
From my observations, here is what I came up with. The pyrevisionstore crate is
both compiled as a dependency of the bindings crate, and as a library to be
used in python. Therefore, its Cargo.toml contains a '[lib]' section, the
presence of this section forces the crate to be compiled into a
"libpyrevisionstore.{rlib,so}", while all the regular crates have a hashed
suffix like "libedenapi-2b9975ec9b865e87.rlib".
None of this would usually matter, but our build system re-uses the build
directory to then compile the pyrevisionstore library. While doing so, it will
re-create the "libpyrevisionstore.{rlib,so}", but not in an identical fashion.
After this, the rest of the build succeeds.
Once a file in the bindings crate is touched, recompiling will only recompile
its file, and not the pyrevisionstore crate, but since
"libpyrevisionstore.{rlib,so}" is different, it now fails to compile...
A previous effort tried to compile each top level target into a separate
directory, but that directly affected some of our tests. Since the underlying
issue is that pyrevisionstore is compiled twice, let's simply not compile it as
a top-level target and simply fold it into the bindings lib. Ideally, we would
want to do the opposite, but let's do that at a later time.
Reviewed By: DurhamG
Differential Revision: D15381038
fbshipit-source-id: 047cfab794371464942f19084ffb9240e836cb40
Summary:
The debugrefreshwatchmanclock command opens a transaction which triggers
commitcloud background backup. This is pointless, as it doesn't actually
make any changes that need backing up.
Set ignoreautobackup to prevent the backup.
Reviewed By: mitrandir77
Differential Revision: D15354508
fbshipit-source-id: 1460ed0ac227f5918a6bf3fea6860d7d2f077d0d
Summary:
There are multiple reports that the work in the commit message editor gets lost
for various reasons. We have `.hg/last-message.txt` for commit hook failure,
but that one does not take care of all code paths (ex. metaedit).
This diff changes `ui.edit` directly to try to save messages in `.hg/edit-tmp`
for 2 weeks.
Reviewed By: kulshrax
Differential Revision: D15347831
fbshipit-source-id: 9207adf4315d94a4892685a03f323e89d9c4a7f1
Summary:
For now, when the indexedlog is enabled, mirror all the writes done by memcache
to the indexedlog. This should give us more testing of both code path.
This will be submitted once a new hg_memcache_client build is published.
Reviewed By: quark-zju
Differential Revision: D15247640
fbshipit-source-id: 74e21731486b991dd9dcf2ce323d34e18cdeb0af
Summary: Do not try to update accessed bookmarks file if there wasn't pulled bookmarks. Currently it rewrites the file even with an empty list of bookmarks.
Reviewed By: quark-zju
Differential Revision: D15165791
fbshipit-source-id: 8eb3b137332c741324b9da9455e3d0dba31bbeda
Summary: Remotenames are shared between the shared repos. The enabled file should be stored in the same place so the config change would be consistent for all the checkouts.
Reviewed By: quark-zju
Differential Revision: D15165789
fbshipit-source-id: c08af95a6b3e5d391cdf8b3ae8ef9b8e3514dbe4
Summary:
We want to migrate the tests to run using treemanifest. As part of
that, we want to first transition to using treemanifest without actually
changing the hash, so we can check that the tests still work first, then update
the hashes second.
This diff adds the flatcompat mode and enables it by default. A future diff will
start enabling treemanifest for existing tests.
Reviewed By: quark-zju
Differential Revision: D15030252
fbshipit-source-id: 06c82be749282d62f1d9cfb43246695c427f8165
Summary:
The Hyper-based EdenAPI client proved to be problematic in practice due to various difficult to debug issues with Tokio, Hyper, TLS, and h2. We have kept it around for the time being while building out the Curl based client in case we wanted to revert back to a pure Rust solution.
Today, the Curl client works well, and future work on the EdenAPI will involve adding more functionality to it. Given that both the Hyper and Curl clients implement the EdenAPI trait, modifications to the trait involve updating both clients. So far this has been acceptable because the updates have been minor, but we would now like to add substantial new functionality to the trait (namely tree fetching), and adding this functionality to the Hyper client would take nontrivial effort.
Given that we aren't using this client at all, let's just delete it. We can always bring it back from the repo's history if we need it in the future.
Reviewed By: quark-zju
Differential Revision: D15289196
fbshipit-source-id: d9c0c3cfc5087c3e080a9919dd9e627b9657676c
Summary:
For now, only pack-file based stores implement MutableHistoryStore, but once
the trait is implemented for stores that are updated in place, returning a Path
on close will not make much sense.
Reviewed By: kulshrax
Differential Revision: D15285970
fbshipit-source-id: 011db2b60c11c1eebfe11881cfc5ebafa1676704
Summary:
While it makes sense that closing a datapack returns the path, it doesn't
really mean anything for an update in place store. Let's change the API to
return an Option<PathBuf>.
Reviewed By: kulshrax
Differential Revision: D15285969
fbshipit-source-id: 804acd75607e86a0bc875910f6aaa300a5526558
Summary: The edenapi is now independant of the storage type for history data.
Reviewed By: kulshrax
Differential Revision: D15284355
fbshipit-source-id: 72a5db42bb0fb19ee03155b13914202581ab5966
Summary:
The python mutablehistorypack can implement MutableHistoryStore, so let's do
it.
Reviewed By: kulshrax
Differential Revision: D15284357
fbshipit-source-id: e55818e2432573f0fbe4f5b73c592f7f6418785c
Summary:
The type of store where data is stored is now fully abstracted to the python
bindings. For now, edenapi will write to the pending mutabledatapack, but we
can now switch it easily to any other store implementing MutableDeltaStore,
including an IndexedLogDataStore.
Reviewed By: kulshrax
Differential Revision: D15266191
fbshipit-source-id: 638cf90a567ef170e0302376312c4b82e6d6b6da
Summary:
The python mutabledatapack is a delta store, and therefore we can implement the
MutableDeltaStore trait for it.
Reviewed By: kulshrax
Differential Revision: D15266192
fbshipit-source-id: 6cc04e4a5e792d037d17c706a374f6864a2902a9
Summary: Adds tracing for mergedriver and for the individual generators.
Reviewed By: quark-zju
Differential Revision: D15223926
fbshipit-source-id: c0c6e1a6814f59fda3ddd75eee901a60a2335c1b
Summary:
Set the `component` to `"commitcloud"` for commit cloud statuses and
messages, rather than using custom highlight functions.
Reviewed By: quark-zju
Differential Revision: D15201944
fbshipit-source-id: 7635942a5ca029209711a2b89c32cc5fd677d22f
Summary:
Add optional prefix keyword arguments to `ui.write` (and thus `ui.status`,
`ui.warn`, etc.). These prefixes can be used to indicate an error condition,
some notice to the user, or to mark a message as coming from a particular
component. The prefixes are labelled so that they can be colored to stand
out from the surrounding text. The default colors are red for errors, yellow
for notices, and cyan for components.
Add a component parameter to `error.Abort` (and thus any exception that
inherits from it) that can be used by callers to mark which component is
responsible for the exception. When the error is printed, the component is
passed as the component prefix of the error message.
Reviewed By: mitrandir77
Differential Revision: D15201946
fbshipit-source-id: 02e3da40e9563704fa1d7ce81366e6e7f66c7f34
Summary:
While closing the repo, hg_memcache_client is terminated, and later, the
pending packfiles are commited. Unfortunately, the commit phase is also when
the content of the pending packfiles will be sent to memcache, and since the
connection is at this point closed, nothing is sent then.
Reviewed By: quark-zju
Differential Revision: D15247639
fbshipit-source-id: 8719cb8bbc3c9571b9cfe250ba4be2b745e4ba15
Summary:
With the mutablestores, this code was starting to be too messy and hard to
follow. Let's simplify it a bit.
Reviewed By: quark-zju
Differential Revision: D15200748
fbshipit-source-id: 2c0cc5a4ff5057f7a9590fcc602afc2b1cc72dcd
Summary:
The `finally` block relies on this name being in scope. If the exception
happens before this name is initialized, the finally block also throws and we
loose the original root cause exception.
Reviewed By: singhsrb, HarveyHunt
Differential Revision: D15244583
fbshipit-source-id: fd8be11987c3028f775a62cb3ae308b30a9d5e75
Summary:
`visibility.add` expects to be given a list of nodes. From reset
we pass a single node which makes the underlying code break it up.
Reviewed By: singhsrb
Differential Revision: D15207234
fbshipit-source-id: 9e0dd0cc8dde0eac69d20816923b39f20963237c
Summary:
I wanted this feature in multiple cases. For example, I have renamed
`segdag::SegDag` to `segment::Dag`, and want to edit commit message for
`D15055347::D15055347`, a 9-diff stack. Editing them one by one is
painful.
Reviewed By: singhsrb
Differential Revision: D15188668
fbshipit-source-id: c7cc11aca0a5e16992b5246a74346a35bec00770
Summary:
We already had tracing for tree prefetches, but in some cases the
fetching happens ondemand and goes through a different code path. Now that we
have pack file receive size tracking, let's annotate this appropriately.
Differential Revision: D15172482
fbshipit-source-id: 2db1dc8464ed9e0b8f6987718c448e391744f445
Summary: This will let us get a feel for download speeds.
Reviewed By: kulshrax
Differential Revision: D15168153
fbshipit-source-id: 86291b8eb3393d54271d574250291ed691a64a86
Summary: Records how many memcache misses we hit.
Reviewed By: kulshrax
Differential Revision: D15168154
fbshipit-source-id: 53e105999d0af566666fcfaecc5bcaf414c5e804
Summary:
Adds tracing support for recording how many bytes we download for lfs,
including the download speed.
Reviewed By: kulshrax
Differential Revision: D15167587
fbshipit-source-id: fb76bbf15cd44dcef2601d9e750794816d273120
Summary:
The prefetch code was not refreshing the pack stores after writing
stuff into packs. This meant that in some cases we would execute a prefetch,
then when we went to read an entry from the store it wouldn't be found. That
would trigger a one-by-one download, which would happen to trigger a pack store
refresh (since remotecontentstore had a refresh) which would cause the rest of
the prefetched data to then become visible.
This fixes it to make prefetch responsible for refreshing the pack data.
This also caused issues where prefetching lfs files requires the hg fetching to
get the metadata, then it reads that metadata and does an lfs fetch. Since the
original metadata wasn't visible (since the packs had not refreshed), this
resulted in infinite recursion until the default 100ms refresh time passed.
Differential Revision: D15171701
fbshipit-source-id: 190b1da542675265efaad75a2a6826cbe3c9631c
Summary:
File that tracks accessed bookmarks doesn't interact with anything else and doesn't really need repo.wlock. However if does use wlock, hg commands like `hg log -r`, which normally are read-only, start waiting for the lock and thus are blocked by other writing commands, that might be running in different checkouts of the same repo.
Let's use a different lock for this feature.
Reviewed By: simpkins
Differential Revision: D15165788
fbshipit-source-id: f04c7196d51db67069c6420545be24d2b7c0af27
Summary:
`infinitepush.sqlindex` depends on `mysql.connector`, which is only needed on
infinitepush servers using the sqlstore, and may not be otherwise available.
Delay the import of this module until we know for sure that it is needed.
Reviewed By: ikostia
Differential Revision: D15197758
fbshipit-source-id: 34f166ceab2530c875a4539089e544755f199b7b
Summary:
Do not keep all revlogs in memory. Detect memory usage and drop filelogs on
demand.
Reviewed By: ikostia
Differential Revision: D15186221
fbshipit-source-id: 8311d479e8dd4f8f449981873a98940410c20c9e
Summary:
On a memcache miss, let's put the server data into a pending packfile. This
will greatly reduce the number of packfiles being created, and thus reduce the
need to run repack.
Reviewed By: DurhamG
Differential Revision: D15154509
fbshipit-source-id: 661efd7fde4fc4f3f6441eebeaf7d3ff4c43871a
Summary:
The code to handle pending mutable packs was effectively duplicated in 3
places. The new class allows refactoring of all of it. The use of several
lambdas is unfortunate, but required as the repo and the cache path are dynamic
and can't be obtained when constructing the pendingmutablepack object.
Reviewed By: DurhamG
Differential Revision: D15023059
fbshipit-source-id: 1eae68fe66ce741eb36baa0c8db318ba32957b41
Summary:
This diff adds a new progress reporting framework to the Eden API crate and uses it to power progress bars for HTTP file downloads in Mercurial.
The new `ProgressManager` type is designed to aggregate progress values across multiple concurrent HTTP transfers. The API is currently designed to integrate well with libcurl's progress callback API, allowing all of the curl handles within a curl multi session to concurrently report their progress.
This progress can then be reported (in aggregate) to a user-provided callback. In most cases, this callback will be a Rust wrapper around a callback provided by the Python code. The `EdenAPI` trait and FFI bindings have been updated accordingly to allow optionally passing in a callback for long-running operations.
Lastly, in `remotefilelog`'s Python code, the callback is specified as a Python closure that simply updates the progress bar.
Reviewed By: quark-zju
Differential Revision: D15179983
fbshipit-source-id: ee677b71beff730f91aafe0364124f7ea0671387
Summary:
This introduces `repo.sqlreporeadonlystate()`, which works similarly to `repo.sqlisreporeadonly()`, but also gets the reason why the read only state is the way it is.
The underlying goal is to use this in a repo hook to report the lock state.
I retained the `sqlisreporeadonly` function so that we don't need to synchronize deployment of this code and the underlying hook.
Reviewed By: quark-zju
Differential Revision: D15165946
fbshipit-source-id: 0a62147167fa826b575178dd261990a956b5f317
Summary:
Move all the store creation and access code into bundlestore. Clean up the
interfaces to the index and store, removing the abstract base classes as no
code was being shared.
Reviewed By: DurhamG
Differential Revision: D15170164
fbshipit-source-id: f22ec4a266333b3100074b21cf9577c82f56e4c6
Summary:
Add support for the `unamend` command. It should use the mutation predecessors
if mutation is enabled, and update the visibility of the commits.
Reviewed By: quark-zju
Differential Revision: D15146976
fbshipit-source-id: e9ee4d26f45ba9e5c3c05a7bca80c8ac326adb9c
Summary: Per title, `hg debughttp` now prints out the hostname that the API server reports rather than the hostname in the URL we used to connect to it. The reason for this is that if the API server is behind a VIP, we get the actual hostname rather than just the VIP URL.
Differential Revision: D15170618
fbshipit-source-id: 9af5480f9987d8ea9c914baf3b62a00ad88d1b32
Summary: The packfile code already does the sort, no need to do it twice.
Reviewed By: DurhamG
Differential Revision: D15154517
fbshipit-source-id: 6ecfc65315a7e443e0c385a5a011f1b491b3f6ac
Summary:
The caller specifies whether data or history or both is needed. Let's only
download what is requested to avoid the network transfer and the disk usage.
Reviewed By: DurhamG
Differential Revision: D15151457
fbshipit-source-id: 5f8600e2ef6c45a98e05b17448fcee8d6574fa36
Summary:
We have an existing method which can capture the desired functionality
without dropping all the data in the `revision_references` table. This
primarily solves these problems:
- Reuse of code.
Reviewed By: farnz
Differential Revision: D15107057
fbshipit-source-id: 5f9970ffd13536808c1b201481b6d2015fbe8295
Summary: Added logging of a number of the currently tracked accessed remote bookmarks.
Reviewed By: mitrandir77
Differential Revision: D15080683
fbshipit-source-id: c03c417afcd24683998689365c893d9e16f265f8
Summary:
Track remote names that are used as destination for hg update.
Resolving name in the repo happens actually twice: as validation during parsing and tokenization of the given specs and actual resolving. This is still fine to update file with used bookmarks twice, because the update/pull operations are much heavy, and updating the file won't make things much slower. Implementing kind-of-cache for used remote names so we could update the file once, isn't worth it, as the feature will be temporarily enabled and won't be needed after the selective pull rollout.
Reviewed By: markbt
Differential Revision: D15048105
fbshipit-source-id: 5b03443a6ab349e3bd88613d21e7b1efdc1ff6cf
Summary: `accessed(..)` method will allow to log the fact of a name access, that is needed to track interesting remotenames.
Reviewed By: markbt
Differential Revision: D15047919
fbshipit-source-id: 29566653e742b3f24b742ffce2282baed833ea61
Summary:
Tracking remote bookmarks that was pulled with
```
hg pull -B <remote name>
```
All these remotenames, if they exist, will be stored in `.hg/selectivepullusedbookmarks` file.
It will allow us to estimate how much memory do we need to keep remote names in sync state in Commit Cloud and automatically mark collected remote bookmarks as "interesting" when the selective pull will be enabled.
Reviewed By: markbt
Differential Revision: D14912903
fbshipit-source-id: 3001869175553327c0840e2cfb829724dfd82893
