Summary: Rename this benchmark to a specific name so that we can add new benchmarks.
Differential Revision: D26947362
fbshipit-source-id: a1d060ee79781aa0ead51f284517471431418659
Summary:
S3 blobstore is sensitive to the number of open connections and it causes perf
problems. Let's add a way to limit the number of simultaneous open connections.
Also see D26911520
Reviewed By: krallin
Differential Revision: D26911679
fbshipit-source-id: 1e3e4922b26d0a29c94c89b4aa76b9b5928effe6
Summary:
When generating hg changesets from git changesets we can run into a situation
where two git commits are almost completely identical with the exception of
committer field. Currently it results in us generating identical mercurial
changesets for different bonsai changesets, and this is something we do not
allow.
Let's do the same thing as hggit does i.e. record committer field in extras if
committer is different from author.
In case of ambiguities (i.e. committer extra is already set, or committer date is set but committer name is not) I opted for returning an error instead of trying to guess what the correct field should be.
Reviewed By: farnz
Differential Revision: D26867740
fbshipit-source-id: 6271e2f7ad421bec296c60ff211723c2162878c6
Summary:
Similar to `output()`, and `error()`, provide a `progress()` to support setting
progress without needing `&IO`.
Reviewed By: andll
Differential Revision: D26886278
fbshipit-source-id: a54563a9cf1d9d1cdb9dabe945aeb5ed1d84e8fb
Summary: Make sure the progress is not hidden because of buffering.
Reviewed By: singhsrb
Differential Revision: D26886277
fbshipit-source-id: d44e48e67b4529a181dd36c30e92608654d8fea6
Summary:
Written by Martin von Zweigbergk at https://phab.mercurial-scm.org/D9551,
or https://www.mercurial-scm.org/repo/hg/rev/bdc2bf68f19e.
He suggested it and it's a useful feature. I did minor compatibility changes
(encoding, avoid rev numbers, foo_bar -> foobar).
Original commit message:
I use 3-way conflict markers. Often when I resolve them, I manually
compare one the base with one side and apply the differences to the
other side. That can be hard when the conflict marker is large. This
patch introduces a new type of conflict marker, which I'm hoping will
make it easier to resolve conflicts.
The new format uses `<<<<<<<` and `>>>>>>>` to open and close the
markers, just like our existing 2-way and 3-way conflict
markers. Instead of having 2 or 3 snapshots (left+right or
left+base+right), it has a sequence of diffs. A diff looks like this:
```
------- base
+++++++ left
a
-b
+c
d
```
A diff that adds one side ("diff from nothing") has a `=======` header
instead and does not have have `+` prefixed on its lines. A regular
3-way merge can be viewed as adding one side plus a diff between the
base and the other side. It thus has two ways of being represented,
depending on which side is being diffed:
```
<<<<<<<
======= left
contents
on
left
------- base
+++++++ right
contents
on
-left
+right
>>>>>>>
```
or
```
<<<<<<<
------- base
+++++++ left
contents
on
-right
+left
======= right
contents
on
right
>>>>>>>
```
I've made it so the new merge tool tries to pick a version that has
the most common lines (no difference in the example above).
I've called the new tool "mergediff" to stick to the convention of
starting with "merge" if the tool tries a regular 3-way merge.
The idea came from my pet VCS (placeholder name `jj`), which has
support for octopus merges and other ways of ending up with merges of
more than 3 versions. I wanted to be able to represent such conflicts
in the working copy and therefore thought of this format (although I
have not yet implemented it in my VCS). I then attended a meeting with
Larry McVoy, who said BitKeeper has an option (`bk smerge -g`) for
showing a similar format, which reminded me to actually attempt this
in Mercurial.
Reviewed By: DurhamG
Differential Revision: D26947920
fbshipit-source-id: 8b4446862897ff9a6dfdf5a2e35617d4db09e883
Summary:
Add a check to ensure the `into_vec()` fast path do not take the full vec if
the `Bytes` is sliced.
Reviewed By: andll
Differential Revision: D26966453
fbshipit-source-id: 538dfb8ca2f01a46d1ede7b98b7f0a30fc7a786e
Summary:
VS Code is seeing issues where they are accidentally triggering
multiple hg status calls, which trigger multiple expensive watchman queries.
While they're trying to track down why this is happening, they'd like a config
that would enable hg to only run one of their status calls at a time.
Reviewed By: quark-zju
Differential Revision: D26931193
fbshipit-source-id: 3b36ac06217bb506110b8d708d4a74378245d5bb
Summary:
RepoError prints `!` at the end of `abort:`. This maintains the old behavior
and should fix test breakages like:
$ hg clone 'ssh://fakehost|touch%20owned/path'
destination directory: path
- abort: no suitable response from remote hg!
+ abort: no suitable response from remote hg
[255]
Reviewed By: DurhamG
Differential Revision: D26964146
fbshipit-source-id: 2e6d095b82ce1e2e23a353cf8f06ae844ee872d7
Summary:
I am not sure why the integration tests didn't fail for this one. I know that
a similar issue was caught last week. Probably one of those cases where not
all tests ran. Anyway. SegmentedChangelogManager requires bookmarks now.
It's not going to use them with the way to SegmentedChangelog is built. Using
the bookmarks needs another code change.
I noticed this because it was failing the Tailer. It will crash Mononoke too.
Long story on why the tailer uses this codepath. Needless to say, we don't want
Mononoke crashing so FIX :)
Reviewed By: quark-zju
Differential Revision: D26962608
fbshipit-source-id: 6efafc67f0816792b841af2cc456edc0cc579460
Summary:
There are a report of slow smartlog that tries to show 8M nodes in `draft()`.
That is an issue after the automatic bookmark clean up, and the visible heads
incorrectly make large amount of commits draft.
Reviewed By: kulshrax
Differential Revision: D26934644
fbshipit-source-id: 0c0890f8eaf1422dab9c03159a419800ae7247ca
Summary:
We're seeing issues where watchman is frequently having to recrawl the
repository due to fsevents getting dropped. We believe this is caused by large
amounts of IO, but we're not sure from what process (buck? hg? arc? ide?). Let's
add some logging to Mercurial to estimate when a checkout triggers a recrawl.
Reviewed By: xavierd
Differential Revision: D26931996
fbshipit-source-id: 0026c792f0ec216cb3e98424da819c4c6e925072
Summary:
Using a more specific name. Looking to differentiate between tailer update
and in process dag update.
Reviewed By: krallin
Differential Revision: D26770844
fbshipit-source-id: b35e6e705a0bfac6289c70a8e8e8cb9ba38a8d99
Summary:
Our production setup has an OnDemandUpdateSegmentedChangelog that gets updated
in various ways. With a setup where the dag is reloaded completely from saves,
we need a factory for the OnDemandUpdateSegmentedChangelog.
SegmentedChangelogManager takes the role of being the factory for our
production Dags.
At some point we will remove the SegmentedChangelog implementation for Manager.
Reviewed By: krallin
Differential Revision: D26708173
fbshipit-source-id: b3d8ea612b317af374f2c0ce6d7c512e3b09b2d2
Summary:
The manager was added as a high level abstraction for storing and loading a
SegmentedChangelog. It worked well when we had one configuration for
SegmentedChangelog. The problem now is that SegmentedChangelog has various
configurations. Storing and loading is an asymetric operation.
In contexts where we do storing we want to have used a specific configuration,
one that operates on an owned dag and has an IdMap that writes to the database.
Then, when running on the server we never store, our writes to the idmap are
in process only and the iddag is wrapped in layers that keep it up to date.
The manager would have to be too complicated to handle all these scenarios.
The solution here is to simplify the manager to cater to the server use case
and inline the logic for the saves where it is used (seeder and tailer).
Reviewed By: krallin
Differential Revision: D26921451
fbshipit-source-id: aedf4acf4bc8371a5d0b249f8bccd9447e85ae0a
Summary:
At the same time remove SqlIdMapFactory. Consolidate the details surrounding
building the IdMap in this factory by moving the logic for caching and in
memory construction from the Manager to the factory.
Reviewed By: krallin
Differential Revision: D26708177
fbshipit-source-id: a6a7f6270c2508adf85f529eef2c75653d002cd0
Summary:
Consolidating on the SegmentedChangelog suffix for the structures in the
`segmented_changelog` crate.
Reviewed By: quark-zju
Differential Revision: D26891996
fbshipit-source-id: 75192bed9cc073adfe7b82ac2b60516ac6629b76
Summary:
Consolidating on the SegmentedChangelog suffic for the structures in the
`segmented_changelog` crate.
Reviewed By: quark-zju
Differential Revision: D26892000
fbshipit-source-id: 47c6ece8aa7ef13e3ea51bbe558655e3f61fdedf
Summary:
Consolidating on the SegmentedChangelog suffix for the structures in the
`segmented_changelog` crate.
Reviewed By: quark-zju
Differential Revision: D26892003
fbshipit-source-id: ad1ccb8c359e7cd5b58d053aa13ed908252988b0
Summary:
Consolidating on the SegmentedChangelog suffix for the structures in the
`segmented_changelog` crate.
Reviewed By: quark-zju
Differential Revision: D26891998
fbshipit-source-id: 86576a029f851e0ac4a6d6600a8839289c9f1f93
Summary:
Consolidating on the SegmentedChangelog suffix for the structures in the
`segmented_changelog` crate.
Reviewed By: quark-zju
Differential Revision: D26892002
fbshipit-source-id: df52027a7c20684c0d46b7adc80692d262b669d4
Summary:
The macro helps with implementing SegmentedChangelog interface for the
structures that rely on another SegmentedChangelog.
Reviewed By: quark-zju
Differential Revision: D26892001
fbshipit-source-id: 6e5f1f04b47f814cf7ed6fd67f4797c5270ba701
Summary:
Consolidating on SegmentedChangelog for the structures in the
`segmented_changelog` crate. We treat these structures as a specific kind of
dag and we name them specifically.
The `dag` crate can have the Dag structures. The `dag` crate generalizes the
graph concept. Dag for generalization, SegmentedChangelog for specific use.
The migration on the DB is simple. We will stop the tailer processes and copy
the data from `segmented_changelog_bundle` to `segmented_changelog_version`.
We will then update the jobs to an ephemeral package that uses
`segmented_changelog_version`. We will remove the old table a week later.
Reviewed By: quark-zju
Differential Revision: D26891997
fbshipit-source-id: e0061973942defa09493b4d23c89d2aaed40825a
Summary:
Visible heads can overlap with scratch remote bookmarks, and in bad cases
(before D26792731 (7a759b6075)), overlap with public remotenames.
When we remove remotenames we need to remove referred nodes in visibleheads
too so we don't end up with massive draft commits.
Reviewed By: DurhamG
Differential Revision: D26954215
fbshipit-source-id: 91010e6608d0150ecf374ce31705e97712154b27
Summary:
Scratch remote bookmarks are considered draft() and were not cleaned up.
Practically there are users with 100+ scratch remote bookmarks. Let's
clean them up too.
Note the commit still remain visible, which will be fixed in upcoming
diffs.
Reviewed By: DurhamG
Differential Revision: D26954216
fbshipit-source-id: e84f99e4e914f0c5169583fc9f60084f23664e02
Summary:
Current `block_on_future` implementation is not safe, as it does not panic on nested calls. Nesting `block_on_future` calls causes starvation of tokio scheduler processes and eventually will lead to deadlock if nested too many times
This diff simply calls `block_on_exclusive` from `block_on_future`. When we see that this does not cause problems we can simply remove `block_on_future`
Reviewed By: sfilipco
Differential Revision: D26899522
fbshipit-source-id: 93794bf2c5908421691dfb094d1807266c9ecd8d
Summary:
Like it says in the title. We probably need to find a better way to make sure
we have this everywhere, but for now let's add it here because it's missing.
Reviewed By: StanislavGlebik
Differential Revision: D26949401
fbshipit-source-id: 9325e0a367a1a41fed8997a3a13e0764b9d77e2f
Summary:
Johan Schuijt-Li found they are broken on some CI hosts.
(But other store paths seem okay, which might indicate the fsync list is effective)
Reviewed By: DurhamG
Differential Revision: D26950101
fbshipit-source-id: e3bcd3f77636325be9e9ce8dfded8b17ec68f436
Summary:
This is dependent on by Metagit and I'd like to update Metagit to Tokio 1.0,
possibly independent of Mononoke;
Reviewed By: farnz
Differential Revision: D26945751
fbshipit-source-id: 552c831964f31d155783af87e7931b2c824e2471
Summary: This is intended to be used in Sandcastle / OnDemand use-cases to provide a cleaner state.
Reviewed By: DurhamG
Differential Revision: D26924711
fbshipit-source-id: a37d24a10c99d953e2af842f729ef634cbb2e2f9
Summary:
Walker args to track correct the originating HgChangeset through history are a bit complicated, add a test for them.
Test showed a bug that HgBonsaiMapping wasn't being tracked in ValidateRoute, so added support for that.
Reviewed By: mitrandir77
Differential Revision: D26945254
fbshipit-source-id: 372574b5e9cde530ba8aecaf1bdc7c7d8aaee54b
Summary: A simple debug command to help check ProjectedFS File State on disk
Reviewed By: chadaustin
Differential Revision: D26918172
fbshipit-source-id: 098724fbb0ca1e8eb6798b3ce669a43e2ea576ee
Summary:
Some merge-tools, like kdiff3, are configured to fix end of line stuff.
This code breaks in Python 3.
Reviewed By: quark-zju
Differential Revision: D26932815
fbshipit-source-id: 7601d53616e50961b89bbc4b0340a9fb672293ef
Summary: Surprisingly this wasn't aleady in the glog output. Added it so easier to correlate with other logs.
Reviewed By: StanislavGlebik
Differential Revision: D26946047
fbshipit-source-id: b2f6b8097bd1ea6e18a79aa9ac0363582c858d55
