Except when stated otherwise, the condition used in `smartset.filter` will be
cached. A new argument has been introduced to disable that behavior. We use it
for filters created from `and` and `sub` operations.
This gives massive performance boosts for revsets with expensive conditions.
revset: branch(stable) or branch(default)
before) wall 4.329070 comb 4.320000 user 4.310000 sys 0.010000 (best of 3)
after) wall 2.356451 comb 2.360000 user 2.330000 sys 0.030000 (best of 4)
revset: author(mpm) or author(lmoscovicz)
before) wall 4.434719 comb 4.440000 user 4.440000 sys 0.000000 (best of 3)
after) wall 2.321720 comb 2.320000 user 2.320000 sys 0.000000 (best of 4)
Lazy revset broke the ordering of the `or` revset. We now stop assuming that
two ascending revset are combine into an ascending one.
Behavior in 3.0:
3:4 or 2:5 == [2, 3, 4, 5]
Behavior in 2.9:
3:4 or 2:5 == [3, 4, 2, 5]
We are adding a test for it.
For unclear reason, the performance `or` revset with expensive filter are
getting even worse than they used to be. This is probably caused by extra
uncached containment check or iteration.
revset #9: author(lmoscovicz) or author(mpm)
before) wall 3.487583 comb 3.490000 user 3.490000 sys 0.000000 (best of 3)
after) wall 4.481486 comb 4.480000 user 4.470000 sys 0.010000 (best of 3)
revset #10: author(mpm) or author(lmoscovicz)
before) wall 3.164839 comb 3.170000 user 3.160000 sys 0.010000 (best of 3)
after) wall 4.574965 comb 4.570000 user 4.570000 sys 0.000000 (best of 3)
We use the & operator to combine with subset (since this is more likely to be
optimised than filter) and we enforce the sorting of the result. Without this
enforced sorting, we may result in a different iteration order than the set
_descendent was computed from.
This reverts a bad `test-glog.t` change from 7904906883bd.
Another side effect is that `test-mq.t` shows `qparent::` including `-1` if
`qparent is -1`. This sound like a positive change.
This has good and bad impacts on the benchmarks, here is a good ones:
revset: 0::
before) wall 0.045489 comb 0.040000 user 0.040000 sys 0.000000 (best of 100)
after) wall 0.034330 comb 0.030000 user 0.030000 sys 0.000000 (best of 100)
revset: roots((0::) - (0::tip))
before) wall 0.134090 comb 0.140000 user 0.140000 sys 0.000000 (best of 63)
after) wall 0.128346 comb 0.130000 user 0.130000 sys 0.000000 (best of 69)
revset: ::p1(p1(tip))::
before) wall 0.143892 comb 0.140000 user 0.140000 sys 0.000000 (best of 55)
after) wall 0.124502 comb 0.130000 user 0.130000 sys 0.000000 (best of 65)
revset: roots((0:tip)::)
before) wall 0.204966 comb 0.200000 user 0.200000 sys 0.000000 (best of 43)
after) wall 0.184455 comb 0.180000 user 0.180000 sys 0.000000 (best of 47)
Here is a bad one:
revset: (20000::) - (20000)
before) wall 0.009592 comb 0.010000 user 0.010000 sys 0.000000 (best of 222)
after) wall 0.029837 comb 0.030000 user 0.030000 sys 0.000000 (best of 100)
The previous implementation was consuming the whole revset when asked for any
sort. The addset class is now doing lazy sorting like all other smarset classes.
This has no significant impact in the benchmark as-is. But this is important
to later change.
This test, written after 3.0, is relying on addset being enforced ascending if
both side are ascending. We are about to restore the ordering to 2.9 behavior
(elements are ordered in the order they are specified). We fix the test before
fixing the order.
This add method is enforcing non-laziness, disabling multiple optimisations.
Benchmarks do not spot any significant difference but real usecase may. This
will also be important for further improvements to addset later in this series.
This add method is enforcing non-laziness, disabling multiple optimisations.
Benchmarks do not spot any significant regression but real usecase may. This
even gives some speedup in some cases:
revset #15: min(0::)
before) wall 0.001247 comb 0.000000 user 0.000000 sys 0.000000 (best of 1814)
after) wall 0.000942 comb 0.000000 user 0.000000 sys 0.000000 (best of 2367)
This will also be important for further improvement to addset later in this series.
This add method is enforcing non-laziness, disabling multiple optimisations.
Benchmarks do not spot any significant differences but real usecase may. This
will also be important for further improvements to addset later in this series.
This option controls what version of the binary format to use when creating a new
obsstore file.
Default is still the old format. No safeguards are currently placed around the
option value, but no clueless users are in danger of harm since it is
undocumented.
This new encoding explicitly stores the date and parents allowing a
significantly faster marker decoding. See inline documentation for details.
This format is not yet used to store format on disk. But it will be used in
bundle2 exchange if both side support it. Support for on-disk format is coming
in other changesets.
We add flag to inform that the marker is using sha256 hashes. As format 0 is not
able to handle sha256 hashes (32 bytes long), we plain crash if we even attempt to
encode a sha256 with it.
Different formats will encode metadata in different ways. So we cannot keep the
binary blob in the object anymore. We use a tuple to ensure it is immutable and
hashable.
If a merge is attempted when another merge is already ongoing, we give
the message "outstanding uncommitted merges". Many other commands
(such as backout, rebase, histedit) give the same message in singular
form. Since the singular form also seems to make more sense, let's use
that for 'hg merge' as well.
Diff generation didn't really fail, it recognized that an hg serve server has
failed to start, and thus skipped the diff generation intentionally.
The most common reason for a server to fail to start is that the port was
already in use, so output HGPORT as well, to help finding it (since pgrep -f
'hg serve' is not sufficient, if the command line is something like 'hg -R main
serve')
Without this change, --first causes currently-running tests to explode
in violent and surprising ways when their temporary directory gets
cleaned up. Now we just suppress failure messages from non-first
failures when running in --first mode.
When unshelving and facing a conflict, if we resolve all conflicts in
favour of the committed changes instead of the shelved changes, then
the ensuing implicit rebase is a no-op. That is, there is nothing to
rebase. In this case, there are no extra intermediate shelve commits
to strip either. Prior to this change, the commit being unshelved to
would be marked for destruction in a rather catastrophic way.
The relevant part of the test case failed as follows:
$ hg unshelve -c
unshelve of 'default' complete
$ hg diff
warning: ignoring unknown working parent 33f7f61e6c5e!
diff --git a/a/a b/a/a
new file mode 100644
--- /dev/null
b/a/a
@@ -0,0 1,3 @@
a
c
x
$ hg status
warning: ignoring unknown working parent 33f7f61e6c5e!
M a/a
? a/a.orig
? foo/foo
$ hg summary
warning: ignoring unknown working parent 33f7f61e6c5e!
parent: -1:000000000000 (no revision checked out)
branch: default
commit: 1 modified, 2 unknown (new branch head)
update: 4 new changesets (update)
With this change, this test case now passes.
This just copies the same local sample hgrc, except it sets the
default path to the repo it was cloned from.
This is cut-and-paste from the local sample hgrc, but I think it's
acceptable, since the two pieces of code are right next to each other
and they're small. There is danger of them going out of synch, but it
would complicate the code too much to get rid of this C&P.
I also add ui as an import to hg.py, but with demandimport, this
should not be a noticeable performance hit.
Some examples of the typical configurations that one might want to do
in an .hg/hgrc file. This includes a default-push that happens to
point to the same location as my-fork.
I insist on the myfork terminology for a server-side clone. Bitbucket,
Github, and others have widely popularised this meaning of "fork".
This also includes a gentle nudge to use a repo-specific username,
which is something that people might not instinctively realise is an
option.
A baseset starts without an explicit order. But as soon as a sort is requested,
we simply register that the baseset has an order and use the ordered version of
the list to behave accordingly.
We will want to properly record the order at creation time in the future. This
would unlock more optimisation and avoid some sorting.
Baseset contains already-computed revisions. It is considered "cheap" to do
operations on an already-computed set. So we add attributes to hold version of
the list in ascending and descending order and use them for `fastasc` and
`fastdesc`. Having distinct lists is important to provide correct iteration in
all cases. Altering a python list will impact an iterator connected to it.
eg: not preserving order at iterator creation time
>>> l = [0, 1]
>>> i = iter(l)
>>> l.reverse()
>>> list(i)
[1, 0]
eg: corrupting in progress iteration
>>> l = [0, 1]
>>> i = iter(l)
>>> i.next()
0
>>> l.reverse()
>>> i.next()
0
The baseset is doing more and more smartset magic and using its list-like
property less and less. So we store the list of revisions in an explicit
attribute and stop inheriting.
This requires reimplementing some basic methods.
