Summary:
Fix subtreeiter_create() to avoid calling the `SubtreeIterator` destructor on
an object that it never constructed.
If an error is thrown constructing the `cmpNodes` vector or calling the
`SubtreeIterator` constructor, then the `SubtreeIterator` destructor should
not be called. However, the `subtreeiter_create()` previously used
`Py_DECREF` to clean up the object, which always invoked
`subtreeiter_dealloc()` and called the `SubtreeIterator` destructor.
It looks like a lot of the other python object types declared in this file
have similar problems, and may incorrectly invoke C++ destructors on objects
that were never constructed if something goes wrong during object
initialization. I have not fixed the other types yet as part of this diff.
The initialization logic for each type looks somewhat different, so they will
each need different fixes rather than this simple change of just calling
`PyObject_Del()` rather than `Py_DECREF()`.
Reviewed By: quark-zju
Differential Revision: D8963858
fbshipit-source-id: d610cac16133a7ff2350c17b13b5ebc7b7becc29
Summary:
fastheaddiscovery is a remotenames feature which makes discovery faster but
less precises. For example, it can request more commits from the server than
necessary. That's not a big deal during pulls, but it can be a problem during
push. It may try to push public commits to the server. People can ran into this
behaviour when they pull commit cloud commit from another devserver and this
commit is based on a newer public commit.
Reviewed By: quark-zju
Differential Revision: D8931322
fbshipit-source-id: 03c6f1df23c3742bda12adf40bf477711f7835bb
Summary: debugcolor does not need to be a repo-command.
Reviewed By: singhsrb
Differential Revision: D8944518
fbshipit-source-id: e00144dbe3dee5d1cd45d1c613e33999aa1aaaed
Summary:
The walkconfig hack was to copy the overridden configs (side effect of uisetup,
CLI flags) to new uis. Since we no longer have overridden configs, it's no
longer necessary.
Reviewed By: singhsrb
Differential Revision: D8960878
fbshipit-source-id: c7a2ad8513380c64ee4e4639016aafaa57b9d9ba
Summary:
This commit adds basic tests for testing `globalrevs` in the commits
created via the `hgsubversion` extension.
Reviewed By: quark-zju
Differential Revision: D8925893
fbshipit-source-id: 288042d9c93527e96f5ff50069cab98cd45b780b
Summary:
This commit enables embedding global revisions in commits created via
the `hgsubversion` extension.
Reviewed By: quark-zju
Differential Revision: D8925897
fbshipit-source-id: 17f320dd7b6ca560acb78ba8e5ee26a8a3a6b045
Summary:
This commit just introduces `ui` and `repo` as optional arguments to
the `dispatch` method. This enables testing with custom `ui` and `repo` objects
during the tests.
Reviewed By: quark-zju
Differential Revision: D8925903
fbshipit-source-id: b720bf5fdb94cb08f83c69565b97b81e114a3327
Summary:
Currently, the `hgsubversion` tests use the same `ui` object while
creating the test repository. This commit just refactors and introduces some
methods to ease testing with a custom `ui` object.
This is useful for enabling other extensions together with `hgsubversion`
during the testing.
Reviewed By: quark-zju
Differential Revision: D8925900
fbshipit-source-id: 7c70fe7c9a58b242ab0af10045ce1589c67231b5
Summary:
This commit introduces a class for easily connecting with the test
database required for testing `hgsubversion` extension along with `hgsql`.
Reviewed By: quark-zju
Differential Revision: D8925907
fbshipit-source-id: ebf30a17ef71d62a8b95b52454a99d73fb6a1c0e
Summary:
There is redundant code in the codebase relating to fetching
configuration for database for the purpose of testing. This commit refactors
some code which enables removing the redundant code.
Reviewed By: quark-zju
Differential Revision: D8961806
fbshipit-source-id: f673bfffb80304d98987c9727f6e709fdb742813
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:
`std::env::home_dir` got deprecated [1]. But the replacements are not in tp2
yet (meaning the buck build will fail). So let's silence the warning for now.
As we're here, also fix an incorrect comment.
[1]: https://internals.rust-lang.org/t/deprecate-or-break-fix-std-env-home-dir/7315
Reviewed By: mitrandir77
Differential Revision: D8886248
fbshipit-source-id: aca0334cbc8b710e42c5c86c952f58adcd10ba2c
Summary:
It's similar to acl and notify - not used and can be done using hooks
externally.
Note the bugzilla extension actually works with the Rust config parser,
unlike acl and notify.
Reviewed By: DurhamG
Differential Revision: D8953126
fbshipit-source-id: 43b12666e4d9c03f800395613eed06783aac48b3
Summary:
Similar to the acl extension, notify is not used here and can be implemented
as hooks.
The direct motivation is, it uses weird key in config names that get rejected
by the Rust config parser:
```
hg: parse error: ".../.hgrc":
--> 61:4
|
61 | */a#branch(test) = will_no_be_send@example.com
| ^---
|
= expected equal_sign
```
Although the pest syntax can be updated to support this case, by using
different `name`s for sections, and config names. It seems cleaner to
just drop notify, as it's the only trouble maker.
Reviewed By: DurhamG
Differential Revision: D8953127
fbshipit-source-id: fc7760a32b6ea538cb207c860aadac7b4b58027f
Summary:
It's rarely used here and feels like a burdern to continue support.
It only restricts write access. A well-designed commit hook API should be the
superior solution here.
The direct motivation of the removal is becuase it does not work well with the
Rust config parser. Namely it's the unique extension that treats an empty
section differently from an section that isn't set. That does not play well
with the Rust config parser. While it can be worked around like D8887670, it's
not a very clean soution, and there are other issues making test-acl.t fail.
Therefore, instead of trying to find the remaining weirdness of acl, I figured
it's probably the right call to drop it and redirect users to hooks instead.
Reviewed By: DurhamG
Differential Revision: D8953125
fbshipit-source-id: 209f04423ccdf182b0ba4021b59d26525173d73c
Summary:
Creates used by hg and tp2 should be consistent since there are both buck and
setup.py builds. Switch to use vendored crates generated from tp2 crates-io
Cargo.toml to get the consistency.
Reviewed By: DurhamG
Differential Revision: D8956612
fbshipit-source-id: 5223eafa75fb1da8bcbc9ddb6d81c18adc2d45f7
Summary: Provide better user experience when vpn is off
Reviewed By: quark-zju
Differential Revision: D8950997
fbshipit-source-id: 50db83c1ac3ee11045ecb64e6d8425cb821a0650
Summary:
`test-hgsql-sqlrefill.t` exposes an issue which leads to the
repository ending up in an uncommittable state. This commit fixes that issue by
adding the expected data to the database.
Reviewed By: quark-zju
Differential Revision: D8925906
fbshipit-source-id: 1e0ec827df6e755f72575b03f094b0ca5a400e9b
Summary:
This commit exposes an issue where a successful `sqlrefill` on a
repository which had no data in the database leaves the repository in a state
which can take no further commits.
This exposed issue will be fixed in D8925906.
Reviewed By: quark-zju
Differential Revision: D8925904
fbshipit-source-id: c289c67d90fdb527e6b324ce10f44b0e79e66585
Summary:
`test-hgsql-sqlrefill.t` exposed an issue with `sqlrefill` where the
database is inconsistent with the state of the repository if the repository had
no data in the database before the invocation of `sqlrefill`. This commit fixes
that issue by also updating the `revision_references` table in this case.
Reviewed By: quark-zju
Differential Revision: D8925895
fbshipit-source-id: ca94ba1b3bd168128edc0c845b2fc1439c15181c
Summary:
This commit just introduces some tests for `sqlrefill`.
In particular, it exposes an issue with `sqlrefill` where the heads are not in
sync if the `sqlrefill` is used on a repository which has no corresponding
entry in the database.
Reviewed By: quark-zju
Differential Revision: D8925898
fbshipit-source-id: 46eb388feafd8c7ec61cf9bb61f774055a902867
Summary:
We update two different schemas in the database during the commit and
it makes sense to isolate this logic in a method. As part of this refactor, we
are also removing `_validatependingrevs` dependency on `self.pendingrevs` which
needlessly restricted the scope of the method.
Reviewed By: quark-zju
Differential Revision: D8925905
fbshipit-source-id: 612c908f39f0902784c1807bed01caa0cd67fa53
Summary:
`sqlrecover`, `sqlrefill` and `sqlstrip` use `ui.environ["PWD"]` to
get the current working directory which leads to not respecting the global
`--cwd` option to the Mercurial commands. This commit switches to using
`pycompat.getcwd()` instead which fixes this issue.
Reviewed By: quark-zju
Differential Revision: D8925908
fbshipit-source-id: 743bf3f6dda0a8545b171b01c1f7d3288f2936b7
Summary:
`sqlrecover`, `sqlrefill` and `sqlstrip` use `ui.environ["PWD"]` to
get the current working directory which leads to not respecting the global
`--cwd` option to the Mercurial commands. This commit just introduces a test
case which exposes this issue in `sqlstrip` tests.
Reviewed By: quark-zju
Differential Revision: D8925896
fbshipit-source-id: 0c0e523adc79db8c1357978185d7f157230b9783
Summary:
As an intermediate step in conversion of the `WWW` repository to being
an Mercurial only repository, we will be modifying the `hgsubversion` extension
to start supporting `globalrev` in the commits pulled from the source
Subversion repository.
The `globalrevs` extension needs to allow for creation of commit through means
other than pushrebase for this process to succeed. Therefore, let's introduce a
configuration option for this purpose.
Reviewed By: quark-zju
Differential Revision: D8925894
fbshipit-source-id: ecb253828c0801c1c39f57ccaf2e11992a924e63
Summary:
This commit just uses the `configitem` to specify the default for the
configurations items relating to `globalrevs` extension.
Reviewed By: quark-zju
Differential Revision: D8925901
fbshipit-source-id: 6d4cf10a2e623b94d3a94eeb1f411d784374a4d5
Summary:
Rather than having a comment which specifies that this code path won't
be hit on the client, it's probably better to only execute the new code if the
repository is on the server.
Reviewed By: quark-zju
Differential Revision: D8925902
fbshipit-source-id: 9404ad9e33f95f580d04d5aa3d40225ecc1dc7b4
Summary:
I noticed when `amend --rebase`ing that rebase was refusing to run because my working copy was dirty. That shouldn't happen with `amend --rebase` because the working copy won't move.
I realized you can pass revisions in the rebaseset that won't be rebased, which is what was happening here. So, let's move this check to look at the generated `destmap`, which is the definitive source of truth for what will move.
Reviewed By: quark-zju
Differential Revision: D8921695
fbshipit-source-id: 292e8d14342adf70a4f693d91a9a3f2aad4f2ff9
Summary:
It could take longer than 1 second and cause test failures:
```
--- test-fb-hgext-remotefilelog-sparse.t
+++ test-fb-hgext-remotefilelog-sparse.t.err
@@ -72,7 +72,7 @@
$ hgcloneshallow ssh://user@dummy/master shallow2
streaming all changes
2 files to transfer, 527 bytes of data
- transferred 527 bytes in 0.* seconds (*) (glob)
+ transferred 527 bytes in 3.1 seconds (169 bytes/sec)
searching for changes
no changes found
updating to branch default
```
Reviewed By: singhsrb
Differential Revision: D8884485
fbshipit-source-id: 394e31c19aa83a431bf7456245a367ef673dcef4
Summary: make ux better when waiting for background cloud sync to complete by showing progress bar
Reviewed By: quark-zju
Differential Revision: D8735116
fbshipit-source-id: 94659422a6fb16e540964c8b5f3316b1bb0a837f
Summary:
`download_vendored_crates` is fb LFS specific. Therefore move it.
This should also fix the OSS build.
Reviewed By: DurhamG
Differential Revision: D8944876
fbshipit-source-id: 8cb85bec9d74d60c839a6f7f90b036d5be282bb0
Summary:
This uses the --noconflict flag added in the previous diff to make auto-restacking, as long as there aren't conflicts or a mergedriver run, trivial.
It creates the `amend.autorestack` flag with four options:
- `never`: never attempt to restack.
- `only-trivial`: restack only if the manifest is unchanged (the old behavior). We can remove this after the rollout.
- `no-conflict`: restack if there won't be merge conflicts.
- `always`: always attempt to restack.
Reviewed By: DurhamG
Differential Revision: D8721726
fbshipit-source-id: 620c08f6082033272dde35cb27b199615f16a787
Summary:
A recent refactor changed the location of the lfs helper, but a number
of paths weren't correct so this broke make local. This fixes them.
Reviewed By: singhsrb
Differential Revision: D8922233
fbshipit-source-id: 90b2997c702aabb352052a410d82554dfa083526
Summary:
We need to tweak users of `lfs` to (a) use if from the new location (b) pass
`-l` if `lfs.py` is used on the command line
Reviewed By: quark-zju
Differential Revision: D8894564
fbshipit-source-id: 652b0b4eba00fd1361f10b41a4c749ad4df7bb5f
Summary:
If pulling or pushing to a new remote server, remotenames may call
`journal.record()` many times. Internally it does a few filesystem seek, and it
can be slow. With `recordmany()` we will pay the cost of seeks ony once.
Reviewed By: quark-zju
Differential Revision: D8873998
fbshipit-source-id: 385542bae7f210eb4f0bba3a02a13e7a4ce76d1d
Summary:
When creating the two first-order diffs we are currently diffing the two revs to the parent of rev1. This was something I was playing around with before but actually doesn't make sense. This returns things to diffing rev1 to rev1's parent and rev2 to rev2's parent.
I think the problem I was trying to work around was seeing files appearing to be changed not to do with either rev1 or rev2. The correct fix for this is to only consider files which are in rev1 or rev2.
Reviewed By: quark-zju
Differential Revision: D8904312
fbshipit-source-id: f48bd498cc27ea650a859d7b318f32520f946150
Summary:
Merge drivers can raise exceptions. If they do, we need to restart the rebase without IMM in case they might work without IMM.
Before, we just exited out of merge.update with a positive "unresolved" count. This change raises a proper exception so we don't hit the fallback in D8886238, and have access to the failed files. It also rewrites some logic that was murky.
I think a better approach overall might be to not have driver raise exceptions, and cancel the rebase in that case or otherwise treat that case more harshly. We'd need to change existing drivers in that case. Or we can just handle this case more explicitly by adding a new `type` to `InMemoryMergeConflictsError`.
---
Note that because of the nice fallback in D8886238, all this does is change the line:
```
hit merge conflicts (in 1 file); switching to on-disk merge
```
to
```
hit merge conflicts (in FILE); switching to on-disk merge
```
but it's important to have explicit flow control so we can make future changes with confidence.
---
Reviewed By: quark-zju
Differential Revision: D8886237
fbshipit-source-id: 4e10e960f7a8d8f37de177d0596d2f3da16be4d9
Summary:
As written, merge tools and drivers are responsible for raising `InMemoryMergeConflictsError` themselves. We shouldn't finish merge.update with unresolved files under IMM.
However, we had this fallback in case we missed a spot, and it turns out there was such a spot: D8886237.
D8699551's addition of required parameters to the constructor broke this fallback. So, this adds the parameters back in.
Reviewed By: quark-zju
Differential Revision: D8886238
fbshipit-source-id: 111fcce6a5a38d126c0118208e508c04b7566971
Summary:
Recently there is a high (30%+) chance that the linux build worker times out.
I tracked it down to this test. It hangs forever on a couple of workers.
The process tree looks like:
python,1904510 run-tests.py ...
|-bash,2067768 .../test-fb-hgext-p4fastimport-seqimport-reorg.t.sh
| |-p4,2073159 change -o 3
| |-p4,2073161 change -fi
| |-p4d,2067785 -f -J off
| `-sed,2073160 s: foo: foo IMPORTER_IGNORE_REORG@:
|-{python},2067733
`-{python},2067780
It seems like a deadlock or race condition somewhere. So let's break the long
command to make sure `change -fi` runs after `change -o 3` completes.
Reviewed By: DurhamG
Differential Revision: D8895528
fbshipit-source-id: 504a94943bc31c8c137df65b34b52207de6766f0
Summary:
This lru cache keeps recently accessed revlogs in memory for fast
access. Originally we had it set to 15 since we estimated that would likely be
longer than most directory paths. It turns out this causes significant slow
downs in some of our mirroring jobs because big revlogs, like the root tree, may
be discarded from the lrucache.
So let's crank this up to 100. This should still bound memory nicely, while
giving us better cache hit rates.
Reviewed By: quark-zju
Differential Revision: D8879648
fbshipit-source-id: d7b6e4244a6e403b7299b61de5d469004667497c
Summary:
There were a bunch of unused code warnings because the mutabledatapack
module wasn't exposed as public. This then lead to us ignoring other warnings.
Let's fix all of them.
Reviewed By: quark-zju
Differential Revision: D8895468
fbshipit-source-id: 914c81026469382fcf28015b4a6bce13bad746c2
Summary:
The test reveals some copy handling issues in treestate:
- copyfile can be called to override a previous copyfile source information.
- drop or remove file should reset the file's copy information.
I hope we'll clean up dirstate. The main problem of it is the "setparents" API,
it changes the parents directly, leaving it to the caller to make sure the rest
of the dirstate is in sync with repo and filesystem state. And it's super
unclear what the callers are supposed to do exactly in these cases. Ideally
there is no "setparents" API on dirstate or the repo object. The low-level
building blocks (merge or clean update) would make sure the tree is in a
consistent state and nobody else (esp. rebase) can ever change dirstate parents
directly.
Reviewed By: DurhamG
Differential Revision: D8869842
fbshipit-source-id: b7882dfe60508fa6bbcfb99e30e507dc297a1d83
Summary:
The test reveals some ordering issue with clone failure handling.
`destrepo.close()` could have side effects writing files. So let's do that
before removing the destination repo.
Reviewed By: DurhamG
Differential Revision: D8869843
fbshipit-source-id: 4cf97038dd4545a59dcee3d86bb114efd5794e62
Summary:
fsmonitor would trigger buggylocking before the test extension. So let's update
the test to skip that part if fsmonitor is used.
Reviewed By: DurhamG
Differential Revision: D8869845
fbshipit-source-id: ef88e06be85de472a53d4b678e331a8374ccc9b1
Summary: The test change does not affect correctness to end-users.
Reviewed By: DurhamG
Differential Revision: D8869834
fbshipit-source-id: 4497237ea3d359dae301d99546ab9595c82fae28
Summary:
The test change actually indicates treestate is more correct. Therefore
a comment about the old behavior "doesn't make sense" is removed:
> *_missing_missing_missing-tracked is reported as removed ('R'), which
> doesn't make sense since the file did not exist in the parent, but on the
> other hand, merged-in additions are reported as modifications, which is
> almost as strange.
Reviewed By: DurhamG
Differential Revision: D8869837
fbshipit-source-id: 1102abc9d41f4ec657ce7c8569ef8159e88b2578
