Summary:
`ontoctx` could be `None`. In that case `.hex()` will fail.
Fix it by recording `ontorev` as `None` in that case.
Reviewed By: liubov-dmitrieva
Differential Revision: D10178579
fbshipit-source-id: e7fdcfe1bc59043685b6da790c28c4a83c514043
Summary:
At the moment they are not recorded because setrecordingparams may not be set
before hooks are called.
Also hooks weren't recorded because pushrebasereplacements weren't correctly
set and KeyError was thrown. This diff fixes it
Reviewed By: quark-zju
Differential Revision: D10147933
fbshipit-source-id: ef33d3e4efa7f3c42e7fcc22ee5f6e54068bf1dc
Summary:
In D10023543 stackpush was added, and conflict check can happen earlier. In
that case failed pushrebase wasn't recorded. This diff fixes it.
Reviewed By: quark-zju
Differential Revision: D10119679
fbshipit-source-id: ef12e00a43375151f81a95eec2d9f02db0a9b12b
Summary:
* Rename takelock to dbwritable
The word "lock" is unclear what lock (local or SQL) it is. Make it clear it's
all about database writes.
* Rename waitforlock to enforcepullfromdb
Again, unclear what lock it is. It's also unclear what it does. Rename to
"enforce pull from db" to make it obvious.
* Rename syncdb to pullfromdb
"sync" is unclear about what direction to sync. Use "pullfromdb" to make it
clear. The hook name is unchanged for compatibility.
Reviewed By: phillco
Differential Revision: D10108594
fbshipit-source-id: fff405e2df9e926f5db436ef74cb5a9aacaebdb4
Summary:
This would be useful for investigating individual cases where sql lockheld time
is long.
Reviewed By: phillco
Differential Revision: D10055069
fbshipit-source-id: f3cdd7a198bdec777c12b98dd6a48e87d862c1bf
Summary:
Our hypothesis is that if the prepushrebase hooks take a significant amount of time, the repo state will get out date, causing hgsql to degrade under load.
This uses the previous test to simulate new commits coming in to the database while a single server is busy running prepushrebase hooks. The new code causes a second sync to occur just after running the hooks.
Reviewed By: quark-zju
Differential Revision: D9999683
fbshipit-source-id: 43d2390b476d090a66353555247c9a623386e75a
Summary:
The fast path avoids recreating the bundlerepo in the critical section, which
is like a reliable 0.8s win.
See the docstring in stackpush.py for details. It does not replace all use cases
that the old code path supports. So the old path is preserved.
Since it's a drop-in replacement, make it the default.
Reviewed By: phillco
Differential Revision: D10023543
fbshipit-source-id: eaceb9ae5067ab9040aa10cc65170ae54abd3331
Summary:
Multiple calls to the wrapped function should, in theory, be cached, so that calling them isn't as expensive as the first time.
Let's track what should be cached ourself so we can provide useful output. This is less risky than trying to separate the underlying logic in revlog.py.
Also, properly handle rev numbers (we are called with both) and turn them into nodes.
Reviewed By: quark-zju
Differential Revision: D10023518
fbshipit-source-id: 9a9ac1ed223136ca19d20db2ee6eb1ca11d5ae49
Summary:
Part of push contention debugging. We want to be able to turn this on server-side to see how many uncached manifest reads we're doing.
If `pushrebase.debugprintmanifestreads` is set it'll log to blackbox.
If `pushrebase.debugprintmanifestreads.user` is set it'll also be sent to client logs, which is fine since most pushes are Landcastle these days.
Stolen from my test in D4785464.
Reviewed By: quark-zju
Differential Revision: D9994420
fbshipit-source-id: ff1294dfda2f2774fc6be78e096dad9fd9a28a5e
Summary:
In pushrebase code path, `_getmanifest` needs to be used to obtain the manifest
correctly for pushes from treeonly repos. The merge commit code path missed this
change. Fix it.
Besides, the rename checking code patch can also hit flat manifest errors via
repo.commitctx -> ... -> fctx._copied -> ctx.filenode -> ctx._fileinfo. Patch
that path too.
Reviewed By: phillco
Differential Revision: D9977904
fbshipit-source-id: 8c51aa9cc6bd85b0147d88c61a5af074e36cdb61
Summary:
It was trying to add a recording for non-pushrebase pushes. It did not result
in failure, but it did result in an annoying warning.
Reviewed By: farnz
Differential Revision: D9570530
fbshipit-source-id: de999a60c146cc49a1a5fd057b6037cf9f73e367
Summary:
per @[1070541862:quark]'s suggestion, I attempt to add a verification hook that checks LFS blobs were uploaded before push.
The code execution path looks like this:
`command.py: push()` -->
`exchange.py: push()` -->
......
`exchange.py: _pushbundle2()`
`exchange.py: _pushcheckoutgoing()`
......
And I insert the hook in `exchange.py: _pushcheckoutgoing()`
Reviewed By: quark-zju
Differential Revision: D9212199
fbshipit-source-id: 98e016da81f9df85731771b7d486d03848624bcb
Summary:
This change fixes two problems in pushrebase recording, that will be used to test mononoke pushrebase:
- record correct `repo_id`, it used to be always 0
- `ontorev` truncation, as we store rev as hex string we need 40 bytes instead of 20
Reviewed By: ikostia
Differential Revision: D9398009
fbshipit-source-id: 91add2d75fbb9acf32b99dc952c467d44c2ccbc9
Summary:
The obsmarker does not make much sense on the server repo since the precursor
does not exist. The client can still receive them.
This makes sure even if we turn obsstore on by default, the server won't create
markers.
Reviewed By: DurhamG
Differential Revision: D9236657
fbshipit-source-id: 32cce8c6ce6bd53ce92e17d1e7b048e089b43fe6
Summary:
enables lfs for pushrebase and adds tests.
using
```
> [pushrebase]
> rewritedates = True
```
in the tests so that pushrebase actually changes the hash of the commit
Reviewed By: DurhamG
Differential Revision: D8939281
fbshipit-source-id: a3b95962635bb1f7926889c2869ea79cfca8132d
Summary:
When constructing the pushrebase reply part, we weren't passing the
bundlecaps along, so it was creating a normal flat-manifest changegroup. A
treeonly client that received this would have to translate it to a tree, which
was expensive for pushes that returned a lot of manifests.
The fix is to pass the appopriate bundle caps to the changegroup creation. Since
we don't have access to the bundle1 caps inside a bundle2 part handler, we had
to update the treeonly logic to also pass treeonly=True caps as bundle2 caps.
Reviewed By: StanislavGlebik
Differential Revision: D8958866
fbshipit-source-id: 4d68031aedb61ae4b113ea9376c704c7548f029c
Summary:
If pushrebase.enablerecording and the rest of the parameters are set then let's
save pushrebase requests. It involves saving the changegroup and treemanifest
bundles2 parts to bundlestore, and then inserting an entry into the database
Reviewed By: quark-zju
Differential Revision: D8801602
fbshipit-source-id: bea4f798daa8542541c8d7c4c2a051c8583930a0
Summary:
For request recording we want to treat conflicts separately. Let's add a
special exception for that.
Reviewed By: quark-zju
Differential Revision: D8787567
fbshipit-source-id: 8bee7e1a61763982e74fbaf15a9320d1d565fd76
Summary:
The file is already quite big, and I'm going to add request recording
functionality soon. Let's move it in a separate package
Reviewed By: quark-zju
Differential Revision: D8787566
fbshipit-source-id: c0202d2ebf1e1662d4b02b966035f6cce9d2344e
