Summary:
We will be relying on `pushrequest` to create commits to the
repository without a working copy using the `memcommit` command that will be
introduced in D14177415. Therefore, lets introduce a class method for creating
a pushrequest based on memcommit parameters.
Reviewed By: quark-zju
Differential Revision: D14177413
fbshipit-source-id: fe326e1e2908724b81a95fbf13a05163fb435ada
Summary:
Calculating the file conditions will be a common operation for any
class method which creates the pushrequest object as in D14177413. Therefore,
it makes sense to segregate this functionality.
Reviewed By: quark-zju
Differential Revision: D14177414
fbshipit-source-id: d57919098f372a9cbed13f59e3d3c4e3cc7a0b55
Summary:
This is certainly not required while creating new commits using
stackpush. Therefore, let's change the code to make this optional. See
D14177415 for an example of when specifying the date is not required.
Reviewed By: quark-zju
Differential Revision: D14177422
fbshipit-source-id: 6a8c5bcf8a01d79c46bc4fe1b4cca8ec16f7f0c2
Summary:
`push --new-branch` is very rarely used and it does not make much sense with
checkheads removed (D14179861). Remove it everywhere.
There is still [one user](https://fburl.com/t5hmcxrp) of the
`push --new-branch` flag. Do not remove it just yet.
Reviewed By: singhsrb
Differential Revision: D14212180
fbshipit-source-id: 18f80576ab6464fc36b047a8a35b339231ee9d8e
Summary:
Previously one couldn't use `sendunbundlereplay` to replay a bundle that just
deletes a bookmark i.e. sends only pushkey part. The problem was in that
`bundleoperation.gettransaction` method wasn't called and so a few hook
arguments weren't set.
In order to fix it this diff just calls this method before calling pushkey. The
solution is not clean, but I don't see much better alternatives.
Another smaller change that this diff is doing is changing sendunbundlereplay
command to require `--deleted` flag. This is just for convenience.
Reviewed By: quark-zju
Differential Revision: D14185380
fbshipit-source-id: f511dc0b9906520b7877501b37639d89ada6fc45
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: Just renaming, and another variable as well to look similar
Reviewed By: DurhamG, quark-zju
Differential Revision: D14185033
fbshipit-source-id: e34de690274afd2f2c6e51db21c7b158f6c3452a
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:
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: There was a typo, the timezone is `[1]` and not at `[0]`
Reviewed By: ikostia
Differential Revision: D14147329
fbshipit-source-id: 8ad4bff810ed949a9f8e86d03ef62bc63aaf11bd
Summary:
Backs out D13944829 that add preloading the manifest to pushrebase. In
a situation where you receive tree commits, but the repo is hybrid, this causes
it to try to lookup the bundled tree manifests in the flat manifest revlog.
Let's just back this out for now until we can come up with an appropriate fix,
or move all our repos to treeonly.
Reviewed By: quark-zju
Differential Revision: D14151876
fbshipit-source-id: 0f7419d5b9bcd9d7ce363f4349e9e2e4a86cf713
Summary:
This is a perf optimization. `unbundlereplay.respondlightly` instructs the
server to not produce the pushback parts regardless of what `replycaps` part
of the incoming bundle says. This is important, since the mononoke-hg sync will
send all the bundles in a searialized way, so we want to optimize time where
possible.
Reviewed By: StanislavGlebik
Differential Revision: D14131575
fbshipit-source-id: afec15347d43fa52b1ec64b4ac8ece5b227ccf7d
Summary:
This is to be used from Mononoke->hg sync.
Currently expects only `pushrebase` bundles, e.g. one head and one book to
move.
Reviewed By: StanislavGlebik
Differential Revision: D14116130
fbshipit-source-id: 959a6e51f51e21da5592c84188e294a33057ffaa
Summary:
pushrebase has logic that loops through all the files and builds a list
of what has changed. Unfortunately, Mercurial has some optimizations where if
the manifest isn't loaded already, it tries to only load the manifest delta, and
checks if this might be a good idea by first checking if the file is in the
commit metadata file list. The commit metadata is a list, which makes it a O(n)
scan to check containment. Since we do this for every file, it becomes O(n^2).
To avoid this, let's just make sure the actual manifest is loaded.
Once every repo is a tree repo, we can get rid of the manifest delta
optimization and get rid of the need to prefetch here.
Reviewed By: singhsrb
Differential Revision: D13944829
fbshipit-source-id: c0f33ca650b7956a1f39e961c94678a6f7f380b6
Summary:
Add an option that let's us specify the date of each commit in a pushrebase.
It should be specified via a config option, which accepts a name of a file in
which json dictionary should be stored. Key of this dictionary is a commit hash, value
is a date.
Reviewed By: ikostia
Differential Revision: D13803174
fbshipit-source-id: 6271c18c61399b89c92dce7a4fe63c8fae8dae7c
Summary:
D13853115 adds `edenscm/` to `sys.path` and code still uses `import mercurial`.
That has nasty problems if both `import mercurial` and
`import edenscm.mercurial` are used, because Python would think `mercurial.foo`
and `edenscm.mercurial.foo` are different modules so code like
`try: ... except mercurial.error.Foo: ...`, or `isinstance(x, mercurial.foo.Bar)`
would fail to handle the `edenscm.mercurial` version. There are also some
module-level states (ex. `extensions._extensions`) that would cause trouble if
they have multiple versions in a single process.
Change imports to use the `edenscm` so ideally the `mercurial` is no longer
imported at all. Add checks in extensions.py to catch unexpected extensions
importing modules from the old (wrong) locations when running tests.
Reviewed By: phillco
Differential Revision: D13868981
fbshipit-source-id: f4e2513766957fd81d85407994f7521a08e4de48
Summary:
Move top-level Python packages `mercurial`, `hgext` and `hgdemandimport` to
a new top-level package `edenscm`. This allows the Python packages provided by
the upstream Mercurial to be installed side-by-side.
To maintain compatibility, `edenscm/` gets added to `sys.path` in
`mercurial/__init__.py`.
Reviewed By: phillco, ikostia
Differential Revision: D13853115
fbshipit-source-id: b296b0673dc54c61ef6a591ebc687057ff53b22e
