Sushil khanchi <sushilkhanchi97@gmail.com> [Tue, 16 Apr 2019 02:53:28 +0530] rev 42494
commit: make the error message more specific while aborting branch closing
Differential Revision: https://phab.mercurial-scm.org/D6493
Sushil khanchi <sushilkhanchi97@gmail.com> [Tue, 16 Apr 2019 02:33:54 +0530] rev 42493
commit: add a check if it is trying to close an already closed branch head
It would check if the revision we are going to close is already a
closed branch head and print the error message accordingly.
Differential Revision: https://phab.mercurial-scm.org/D6491
Martin von Zweigbergk <martinvonz@google.com> [Mon, 17 Jun 2019 10:53:00 -0700] rev 42492
strip: move checksubstate() to mq (its only caller)
Differential Revision: https://phab.mercurial-scm.org/D6536
Martin von Zweigbergk <martinvonz@google.com> [Mon, 17 Jun 2019 10:19:41 -0700] rev 42491
strip: use bailifchanged() instead of reimplementing it
This also means that we get the standard error messages (see changed
test cases).
Differential Revision: https://phab.mercurial-scm.org/D6535
Martin von Zweigbergk <martinvonz@google.com> [Mon, 17 Jun 2019 10:40:24 -0700] rev 42490
strip: remove unused excsuffix argument from checklocalchanges()
It was only used by mq, and mq now has its own copy of the function.
Differential Revision: https://phab.mercurial-scm.org/D6534
Martin von Zweigbergk <martinvonz@google.com> [Mon, 17 Jun 2019 10:38:50 -0700] rev 42489
mq: remove dependency on strip's checklocalchanges()
Some of the functionality in strip.checklocalchanges() was only used
by mq, so let's move it to mq so we can clean up strip.
Differential Revision: https://phab.mercurial-scm.org/D6533
Martin von Zweigbergk <martinvonz@google.com> [Thu, 02 May 2019 23:39:33 -0700] rev 42488
copies: avoid calling matcher if matcher.always()
When storing copy information in the changesets
(experimental.copies.read-from=changeset-only), this patch speeds up
hg debugpathcopies FENNEC_58_0_2_BUILD1 FIREFOX_59_0b8_BUILD2
from 5.9s to 4.7s. At the start of this series (
b162229e), that
command took 18min.
Differential Revision: https://phab.mercurial-scm.org/D6422
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 Apr 2019 21:21:44 -0700] rev 42487
copies: avoid unnecessary copying of copy dict
When storing copy information in the changesets, this patch speeds up
hg debugpathcopies FENNEC_58_0_2_BUILD1 FIREFOX_59_0b8_BUILD2
from 11s to 5.9s. That command takes 6.2s when storing copy
information in filelogs.
Differential Revision: https://phab.mercurial-scm.org/D6421
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 Apr 2019 21:22:14 -0700] rev 42486
copies: don't filter out copy targets created on other side of merge commit
If file X is copied to Y on one side of merge and the other side
creates Y (no copy), we would not mark that as copy. In the
changeset-centric pathcopies() version, that was done by checking if
the copy target existed on the other branch. Even though merge commits
are pretty uncommon, it still turned out to be too expensive to load
the manifest of the parents of merge commits. In a repo of
mozilla-unified converted to storing copies in changesets, about 2m30s
of `hg debugpathcopies FIREFOX_BETA_59_END FIREFOX_BETA_60_BASE` is
spent on this check of merge commits.
I tried to think of a way of storing more information in the
changesets in order to cheaply detect these cases, but I couldn't
think of a solution. So this patch simply removes those checks.
For reference, these extra copies are reported from the aforementioned
command after this patch:
browser/base/content/sanitize.js -> browser/modules/Sanitizer.jsm
testing/mozbase/mozprocess/tests/process_normal_finish_python.ini -> testing/mozbase/mozprocess/tests/process_normal_finish.ini
testing/mozbase/mozprocess/tests/process_waittimeout_python.ini -> testing/mozbase/mozprocess/tests/process_waittimeout.ini
testing/mozbase/mozprocess/tests/process_waittimeout_10s_python.ini -> testing/mozbase/mozprocess/tests/process_waittimeout_10s.ini
Since these copies were created on one side of some merge, it still
seems reasonable to include them, so I'm not even sure it's worse than
filelog pathcopies(), just different.
Differential Revision: https://phab.mercurial-scm.org/D6420
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 Apr 2019 00:40:53 -0700] rev 42485
copies: do full filtering at end of _changesetforwardcopies()
As mentioned earlier, pathcopies() is very slow when copies are stored
in the changeset. Most of the cost comes from calling _chain() for
every changeset, which is slow because it needs to read manifests. It
needs to read manifests to be able to filter out copies that are were
created in one commit and then deleted. (It also filters out copies
that were created from a file that didn't exist in the starting
revision, but that's a fixed revision across calls to _chain(), so
it's much cheaper.)
This patch changes from _chainandfilter() to just _chain() in the main
loop in _changesetforwardcopies(). It instead removes copies that have
subsequently been removed by using ctx.filesremoved(). We thus rely on
that to be fast.
It timed this command in mozilla-unified:
hg debugpathcopies FIREFOX_59_0b3_BUILD2 FIREFOX_BETA_59_END
It took 18s before and 1.1s after. It's still faster when copy
information is stored in filelogs: 0.70s. It also still gets slow when
there are merge commits involved, because we read manifests there
too. We'll deal with that later.
Differential Revision: https://phab.mercurial-scm.org/D6419
Yuya Nishihara <yuya@tcha.org> [Sat, 15 Jun 2019 10:58:53 +0900] rev 42484
rust-filepatterns: add comment about Windows path handling
As I replied to the Phabricator message, this is wrong. And I even suspect
it wouldn't compile because of multiple type mismatches.
I think, in Rust where type system is rock solid, we can live with UTF-8
strings except for the bottom storage layer and the top UI/command layer.
We'll still have to get around undecodable characters not to be lost, but
I think it's okay to drop such filenames from match result if they don't
match in UTF-8 world, not in Latin-1 world.
Yuya Nishihara <yuya@tcha.org> [Sat, 15 Jun 2019 10:35:53 +0900] rev 42483
rust-filepatterns: silence warning of non_upper_case_globals
Yuya Nishihara <yuya@tcha.org> [Sat, 15 Jun 2019 10:35:03 +0900] rev 42482
rust: update Cargo.lock to include @generated comment
cargo 1.34.0 of Debian sid inserts this comment, and I'm tired of reverting
the change every time I do make local.
https://github.com/rust-lang/cargo/commit/
bd0e4a08471b8bc7957829b4fd294b8985d4fa2d
Augie Fackler <augie@google.com> [Mon, 17 Jun 2019 13:21:41 -0400] rev 42481
merge with stable
Yuya Nishihara <yuya@tcha.org> [Sun, 16 Jun 2019 12:31:07 +0900] rev 42480
cborutil: fix streamencode() to handle subtypes
Otherwise the template filter 'cbor' could crash because of bytes subclass:
ValueError: do not know how to encode
<class 'mercurial.encoding.safelocalstr'>
Matt Harbison <matt_harbison@yahoo.com> [Fri, 14 Jun 2019 00:30:33 -0400] rev 42479
lfs: correct an error in the TODO file
Matt Harbison <matt_harbison@yahoo.com> [Thu, 04 Oct 2018 00:57:11 -0400] rev 42478
cat: don't prefetch files unless the output requires it
It's a waste to cache lfs blobs when cat'ing the raw data at best, but a hassle
debugging when the blob is missing. I'm not sure if there are other commands
that have '{data}' for output, and if there's a general way to prefetch on that
keyword.
It's interesting that the verbose output seems to leak into the JSON output, but
that seems like an existing bug.
Augie Fackler <augie@google.com> [Wed, 12 Jun 2019 19:01:49 -0400] rev 42477
tracing: add support for emitting counters
Differential Revision: https://phab.mercurial-scm.org/D6526
Augie Fackler <augie@google.com> [Wed, 12 Jun 2019 19:01:37 -0400] rev 42476
tracing: extract tracing-active logic to separate function
I'm about to add support for counters, and want to avoid duplicating this
logic.
Differential Revision: https://phab.mercurial-scm.org/D6525
Augie Fackler <augie@google.com> [Wed, 12 Jun 2019 19:00:46 -0400] rev 42475
catapipe: add support for COUNTER events
Differential Revision: https://phab.mercurial-scm.org/D6524
Augie Fackler <augie@google.com> [Wed, 12 Jun 2019 16:08:21 -0400] rev 42474
demandimport: add tracing coverage for Python 3
This makes things feel a little less mysterious when modules are being
imported.
Differential Revision: https://phab.mercurial-scm.org/D6523
Martin von Zweigbergk <martinvonz@google.com> [Fri, 14 Jun 2019 10:21:47 -0700] rev 42473
export: don't prefetch *all* files in manifest
`hg export` only shows changed files, not all files, but we still
prefetched all files in cmdutil.export(). The same is true for the
other commands calling cmdutil.exportfile(). That meant that `hg
export` with remotefilelog (or lfs, I assume) could take much longer
than expected because it would download all the files in the repo.
Differential Revision: https://phab.mercurial-scm.org/D6532
Martin von Zweigbergk <martinvonz@google.com> [Fri, 14 Jun 2019 13:50:06 -0700] rev 42472
remotefilelog: remove obsolete filtering of treemanifest directories
I think this has been obsolete since
2cf18f46a1ce (narrow: only walk
files within narrowspec also for committed revisions, 2018-09-28).
Differential Revision: https://phab.mercurial-scm.org/D6531
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 14 Jun 2019 18:27:50 +0300] rev 42471
py3: add test-dirstate-race2.t to list of passing tests
This test was added new recently. The py3 buildbot found that it passes, so
let's add it to the list of passing tests.
Differential Revision: https://phab.mercurial-scm.org/D6530
Taapas Agrawal <taapas2897@gmail.com> [Fri, 14 Jun 2019 18:25:14 +0530] rev 42470
strip: during merge allow strip only when -f is used
This ensures to abort strip to `hg strip` when we have a merge
in progress and allow it only when a `--force` flag is used.
Differential Revision: https://phab.mercurial-scm.org/D6529
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 26 Apr 2019 00:48:12 +0200] rev 42469
deltas: set estimated compression upper bound to "3x" instead of "10x"
In pratice, we very rarely observer compression better than "3x" on manifest
deltas. Having a more aggressive estimate significantly helps our pathological
use case on a private repository. Here are a comparison of timings using
different upper bound.
Estimated compression | ø | ×10 | ×5 | ×3 |
timing | 14.11 | 2.61 | 1.96 | 1.53 |
We also tested the impact of this series on an array of public repositories.
This shown no impact in either size nor timing.
Full data set below for those interested.
Size
----
Regarding size, not significant impact have been noticed on neither public nor
private repositories. Here are the number we gathered on public repositories:
zlib/upperbound | no | 10x | 5x | 3x
mercurial | 5 875 730 | 5 875 730 | 5 875 730 | 5 875 730
pypy | 27 782 913 | 27 782 913 | 27 782 913 | 27 782 913
netbeans | 159 161 207 | 159 161 207 | 159 161 207 | 159 959 879 (+0.5%)
mozilla-central | 323 841 642 | 323 841 642 | 323 841 642 | 319 867 519 (-2.5%)
mozilla-try | 746 649 123 | 746 649 123 | 746 649 123 | 741 155 568 (-0.7%)
private-repo | 1 485 287 294 | 1 485 287 294 | 1 485 287 294 | 1 409 248 382 (-5.1%)
zstd/upperbound | no | 10x | 5x | 3x
mercurial | 5 895 206 | 5 895 206 | 5 895 206 | 5 895 206
pypy | 28 689 230 | 28 689 230 | 28 689 230 | 28 689 230
netbeans | 157 636 387 | 157 636 387 | 157 636 387 | 159 692 678 (+1.3%)
mozilla-central | 317 650 281 | 317 650 281 | 317 650 281 | 319 613 603 (+0.6%)
mozilla-try | 737 555 275 | 737 555 275 | 737 555 275 | 738 079 473 (+0.1%)
private-repo | 1 352 362 982 | 1 352 362 982 | 1 346 961 880 | 1 361 327 384 (+0.7%)
Speed
------
Timing gathered using `hg perfrevlogwrite -m`. Value are in seconds.
mercurial
zlib | no | 10x | 5x | 3x |
total | 65.551783 | 65.388887 | 65.260658 | 65.321199 |
max | 0.034544 | 0.034571 | 0.034659 | 0.034521 |
99.99% | 0.034544 | 0.034571 | 0.034659 | 0.034521 |
zstd | no | 10x | 5x | 3x |
total | 49.118449 | 49.054062 | 48.753588 | 48.740230 |
max | 0.009338 | 0.009239 | 0.009202 | 0.009178 |
99.99% | 0.007618 | 0.007639 | 0.007626 | 0.007621 |
pypy
zlib | no | 10x | 5x | 3x |
total | 560.865984 | 558.983817 | 559.083815 | 559.349152 |
max | 0.219614 | 0.215922 | 0.218112 | 0.218107 |
99.99% | 0.219614 | 0.215922 | 0.218112 | 0.218107 |
zstd | no | 10x | 5x | 3x |
total | 349.393280 | 347.395819 | 347.185407 | 345.643985 |
max | 0.084143 | 0.083536 | 0.081834 | 0.082178 |
99.99% | 0.039445 | 0.039639 | 0.039612 | 0.039175 |
netbeans
zlib | no | 10x | 5x | 3x |
total | 33103.327727 | 33314.932260 | 33211.745233 | 33345.891778 |
max | 2.666852 | 2.672059 | 2.662453 | 2.662936 |
99.99% | 2.058772 | 2.070429 | 2.069569 | 2.064653 |
zstd | no | 10x | 5x | 3x |
total | 20112.102708 | 20095.879719 | 20083.390300 | 20123.221859 |
max | 2.063482 | 2.062851 | 2.065229 | 2.060147 |
99.99% | 1.146647 | 1.143794 | 1.142933 | 1.146529 |
mozilla
zlib | no | 10x | 5x | 3x |
total | 41374.102138 | 41418.816773 | 41381.956370 | 41334.280732 |
max | 3.383474 | 3.387400 | 3.405711 | 3.387316 |
99.99% | 1.006755 | 1.005954 | 1.007700 | 1.007373 |
zstd | no | 10x | 5x | 3x |
total | 24689.691520 | 24643.939662 | 24664.630027 | 24664.512714 |
max | 1.460822 | 1.449640 | 1.439747 | 1.465304 |
99.99% | 0.527111 | 0.527377 | 0.527807 | 0.527226 |
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 21 Jan 2019 22:46:31 +0100] rev 42468
deltas: skip if projected compressed size is bigger than previous snapshot
If we have a delta, we check constraints against a lower bound estimate of the
resulting compressed delta. We then checks this projected size against the
`size(snapshotⁿ) > size(snapshotⁿ⁺¹)` constraint. This allows to exclude
potential base candidates before doing any expensive computation.
This only apply to the intermediate-snapshot case since this constraint only
apply to them.
For some pathological cases of a private repository this step provide a
further performance boost (timing from `hg perfrevlogwrite`):
before: 3.010646 seconds
after: 2.609307 seconds
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 21 Jan 2019 22:46:18 +0100] rev 42467
deltas: skip if projected compressed size does not match text size constraint
If we have a delta, we check constraints against a lower bound estimate of the
resulting compressed delta. We then checks this projected size against the ½ⁿ
size constraints. This allows to exclude potential base candidates before doing
any expensive computation.
This only apply to the intermediate-snapshot case since this constraint only apply to
them.
For some pathological cases of a private repository this step provide a
further performance boost (timing from `hg perfrevlogwrite`):
before: 3.145906 seconds
after: 3.010646 seconds
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 21 Jan 2019 22:37:30 +0100] rev 42466
deltas: accept and skip None return for delta info
They are some extra computation that will shortcut the delta compression if the
delta seems hopeless, returning None.
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 21 Jan 2019 22:36:16 +0100] rev 42465
delta: move some delta chain related computation earlier in deltainfo
They are some more optimization change that will make use of this in the
function. So we retrieve the data earlier.
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Thu, 25 Apr 2019 22:50:33 +0200] rev 42464
deltas: skip if projected delta size is bigger than previous snapshot
Before computing any delta, we get a basic estimation of the delta size we can
expect and the resulted compressed value. We then checks this projected size
against the `size(snapshotⁿ) > size(snapshotⁿ⁺¹)` constraint. This allows to
exclude potential base candidates before doing any expensive computation.
This only apply to the intermediate-snapshot case since this constraint only
apply to them.
For some pathological cases of a private repository this step provide a
significant performance boost (timing from `hg perfrevlogwrite`):
before: 14.115908 seconds
after: 3.145906 seconds
Valentin Gatien-Baron <vgatien-baron@janestreet.com>, Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 25 Apr 2019 22:30:14 +0200] rev 42463
deltas: skip if projected delta size does not match text size constraint
Before computing any delta, we get a basic estimation of the delta size we can
expect and the resulted compressed value. We then checks this projected size
against the ½ⁿ size constraints. This allows to exclude potential base
candidates before doing any expensive computation.
This only apply to the intermediate-snapshot case since this constraint only
apply to them.
In practice we only perform this new checks for the manifestlog. Manifest log
combine two property: it is likely to have delta chain issue and its
diffing/compression is fairly predictable.
The initial author of this changeset is Valentin Gatien-Baron providing the
initial idea and initial testing, Pierre-Yves David later consolidated the code
in the right location and run more extensive testing.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 26 Apr 2019 00:28:22 +0200] rev 42462
revlog: add the option to track the expected compression upper bound
There are various optimization we can do if we can estimate the size of delta
before actually spending CPU compressing them. So we add a attributed dedicated
to tracking that.
We only use it on Manifest because (1) it structure is quite stable across all
Mercurial repository so its compression ratio is fairly universal. This is the
revlog with most extreme delta (cf the sparse-revlog optimization).
This will be put to use in later changesets.
Right now the compression upper bound is set to 10. This is a fairly
conservative value (observed value is more around 3), but I prefer to be safe
while introducing the optimization principles. We can tune the optimization
threshold later.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 12 Jun 2019 17:30:24 +0100] rev 42461
perf: clarify some of the custom behavior of `perfrevlogwrite`
This reduce the chance of developers being surprised by special cases.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 12 Jun 2019 16:56:41 +0100] rev 42460
perf: fix perfrevlogwrite --count documentation
The help text was copy pasted from the previous option.
Georges Racinet <georges.racinet@octobus.net> [Fri, 17 May 2019 00:17:43 +0200] rev 42459
rust: switched to 'cargo rustc' in setup.py
This is more flexible in the passing of additional flags, also
what setuptools_rust does, giving less uncertainty about non-Linux
platforms.
Georges Racinet <georges.racinet@octobus.net> [Fri, 14 Jun 2019 11:18:06 +0100] rev 42458
rust-cpython: fix build for MacOSX
MacOSX needs special link flags. Quoting the README of rust-cpython:
create a `.cargo/config` with the following content:
```
[target.x86_64-apple-darwin]
rustflags = [
"-C", "link-arg=-undefined",
"-C", "link-arg=dynamic_lookup",
]
```
This is tested with Python 2.7 (Anaconda install) and Python 3
(Homebrew install)
Georges Racinet <georges.racinet@octobus.net> [Fri, 14 Jun 2019 10:57:07 +0100] rev 42457
rust-cpython: management of shared libray suffix
Before this changeset, the shared library objects suffixes
were both (rustc output and Python input) hardcoded to '.so',
which is wrong for Python3 and non Linux targets.
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Mon, 27 May 2019 16:55:46 -0400] rev 42456
merge: fix race that could cause wrong size in dirstate
The problem is that hg merge/update/etc work the following way:
1. figure out what files to update
2. apply the update to disk
3. apply the update to in-memory dirstate
4. write dirstate
where step3 looks at the filesystem and assumes it sees the result of
step2. If a file is changed between step2 and step3, step3 will record
incorrect information in the dirstate.
I avoid this by passing the size step3 needs directly from step2, for
the common path (not implemented for change/delete conflicts for
instance).
I didn't fix the same race for the exec bit for now, because it's less
likely to be problematic and I had trouble due to the fact that the
dirstate stores the permissions differently from the manifest (st_mode
vs '' 'l' 'x'), in combination with tests that pretend that symlinks
are not supported.
However, I moved the lstat from step3 to step2, which should tighten
the race window markedly, both for the exec bit and for the mtime.
Differential Revision: https://phab.mercurial-scm.org/D6475
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Wed, 12 Jun 2019 13:10:52 -0400] rev 42455
worker: support parallelization of functions with return values
Currently worker supports running functions that return a progress
iterator. Generalize it to handle function that return a progress
iterator then a return value.
It's unused in this commit, but will be used in the next one.
Differential Revision: https://phab.mercurial-scm.org/D6515
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sun, 19 May 2019 16:06:06 -0400] rev 42454
tests: show how the dirstate can end up containing wrong information
which can result in bad status output.
Concretely, this seems to be easily triggered by having a build system
watching the filesystem for changes, and rebuilding files that are
both tracked and generated while an update is happening.
Differential Revision: https://phab.mercurial-scm.org/D6474
Georges Racinet <georges.racinet@octobus.net> [Thu, 23 May 2019 02:05:32 +0200] rev 42453
rust: new rust options in setup.py
The --rust global option turns on usage (and by default compilation)
of the rust-cpython based mercurial.rustext.
Similarly to what's previously done for zstd, there is a --no-rust
option for the build_ext subcommand in order not to build
mercurial.rustext, allowing for an OS distribution to prebuild it.
The HGWITHRUSTEXT environment variable is still honored, and has
the same effect as before, but now it works mostly by making
the --rust global option defaulting to True, with some special
cases for the direct-ffi case (see more about that below)
Coincidentally, the --rust flag can also be passed from the make
commands, like actually all global options, in the PURE variable
make local PURE=--rust
This feels inappropriate, though, and we should follow up with
a proper make variable for that case.
Although the direct-ffi bindings aren't directly useful any more, we
keep them at this stage because
- they provide a short prototyping path for experiments in which a C extension
module has to call into a Rust extension. The proper way of doing that would
be to use capsules, and it's best to wait for our pull request onto
rust-cpython for that: https://github.com/dgrunwald/rust-cpython/pull/169
- Build support for capsules defined in Rust will probably need to reuse
some of what's currently in use for direct-ffi.
Georges Racinet <georges.racinet@octobus.net> [Thu, 30 May 2019 09:14:41 +0200] rev 42452
rust: using policy.importrust from Python callers
This commit converts all current Python callers of
mercurial.rustext to the new policy.importrust system.
After this point, going through policy.importrust
or policy.importmod (in some more distant future)
is mandatory for callers of Rust code outside of
Python tests.
We felt it to be appropriate to keep Rust-specific tests
run inconditionally if the Rust extensions are present.
Georges Racinet <georges.racinet@octobus.net> [Wed, 29 May 2019 13:27:56 +0200] rev 42451
rust: module policy with importrust
We introduce two rust+c module policies and a new
`policy.importrust()` that makes use of them.
This simple approach provides runtime switching of
implementations, which is crucial for the performance
measurements such as those Octobus does with ASV.
It can also be useful for bug analysis.
It also has the advantage of making conditionals in
Rust callers more uniform, in particular
abstracting over specifics like `demandimport`
At this point, the build stays unchanged, with the rust-cpython based
`rustext` module being built if HGWITHRUSTEXT=cpython.
More transparency for the callers, i.e., just using
`policy.importmod` would be a much longer term and riskier
effort for the following reasons:
1. It would require to define common module boundaries
for the three or four cases (pure, c, rust+ext, cffi) and that
is premature with the Rust extension currently under heavy
development in areas that are outside the scope of the C extensions.
2. It would imply internal API changes that are not currently wished,
as the case of ancestors demonstrates.
3. The lack of data or property-like attributes (tp_member
and tp_getset) in current `rust-cpython` makes it impossible to
achieve direct transparent replacement of pure Python classes by
Rust extension code, meaning that the caller sometimes has to be able
to make adjustments or provide additional wrapping.
Navaneeth Suresh <navaneeths1998@gmail.com> [Thu, 13 Jun 2019 23:28:31 +0300] rev 42450
help: add help entry for internals.mergestate
This patch adds an entry for `internals.mergestate` as suggested
by @marmoute. Most of the help text is taken from `merge.mergestate`.
Differential Revision: https://phab.mercurial-scm.org/D6448
Differential Revision: https://phab.mercurial-scm.org/D6528
Ian Moody <moz-ian@perix.co.uk> [Wed, 12 Jun 2019 17:22:37 +0100] rev 42449
phabricator: use parents.set to always set dependencies
Now that Mercurial's Phabricator instance has been updated to a version that
supports the parents.set transaction on revision.edit we can use that to set
dependency relationships in patch stacks instead of abusing the summary.
This has the advantage that we can use it on every `phabsend` so commit
reordering is picked up without spamming changes like abusing the summary would,
and using parents.set will clear previous parents unlike parents.add.
Differential Revision: https://phab.mercurial-scm.org/D6514
amalloy [Fri, 31 May 2019 10:12:56 -0700] rev 42448
help: remove repeated word in 'hg help rebase'
Specifically, the second 'with' in 'with which to merge with'.
Differential Revision: https://phab.mercurial-scm.org/D6483
Kyle Lippincott <spectral@google.com> [Mon, 10 Jun 2019 15:35:06 -0700] rev 42447
rebase: tweak description of inmemory working even w/ dirty working dir
One of our users was confused because they read this, and then attempted to run
`hg rebase` with a dirty working directory, and it still complained. The reason
was that they were attempting to rebase the commit they currently had checked
out, which (at least with evolve workflows enabled) involves updating the
working directory to be based on the newly rebased commit.
Differential Revision: https://phab.mercurial-scm.org/D6507