Back in the time where repo.revs(...) returned a list, calling `len(...)` on the
result was quite common. We reinstall this on _addset.
There is absolutely no easy way to test this from the command line. The commands
using this in the evolve extension will eventually land into core.
Before this patch, internal function "display()" of "hg grep" is not
efficient for "-l"/"--files-with-matches", because loop is continued,
even after the first matching is found in the specified file.
This patch exits loop immediately, if matching is found for
"--files-with-matches".
In this case, "before is None" is equal to "opts.get('files_with_matches')".
Before this patch, internal function "display()" of "hg grep" stores
whether matching is already found or not into the dictionary
"filerevmatches" by "(fn, rev)" tuple as the key.
But this is redundant, because:
- "filerevmatches" is local variable of "display()", so each
"display()" invocations don't affect others
- both "fn" and "rev" (gotten from "ctx" argument) are never changed
in each "display()" invocations
Then, "filerevmatches" should have only one entry at most, and "(fn,
rev) in filerevmatches" should be equal to "found".
This patch uses "found" instead of "filerevmatches" examination for
efficiency.
Before this patch, to check whether the file in the specified revision
is binary or not, "util.binary()" is invoked via internal function
"binary()" of "hg grep" once per a line of "hg grep" output, even
though binary-ness is not changed in the same file.
This patch reuses the first "util.binary()" invocation result by
annotating internal function "binary()" with "@util.cachefunc".
Performance improvement measured by "hgperf grep -r 5e9e7af9ae01 vfs
mercurial/scmutil.py":
before this patch:
! wall 0.024000 comb 0.015600 user 0.015600 sys 0.000000 (best of 118)
after this patch:
! wall 0.023000 comb 0.015600 user 0.015600 sys 0.000000 (best of 123)
Status of recent(5e9e7af9ae01) "mercurial/scmutil.py":
# of lines: 919 (may affect cost of search)
# of bytes: 29633 (may affect cost of "util.binary()")
# of matches: 22 (may affect frequency of "util.binary()")
Before this patch, "util.cachefunc()" caches the value returned by the
specified function into dictionary "cache", even if the specified
function takes no arguments.
In such case, "cache" has at most one entry, and distinction between
entries in "cache" is meaningless.
This patch adds the code path to "cachefunc()" for the function taking
no arguments for efficiency: to store only one cached value, using
list "cache" is a little faster than using dictionary "cache".
If two things were iterating over a generatorset at the same time, they could
miss out on the things the other was generating, resulting in incomplete
results. This fixes it by making it possible for two things to iterate at once,
by always checking the _genlist at the beginning of each iteration.
I was only able to repro it with pending changes from my other commits, but they
aren't ready yet. So I'm unable to add a test for now.
_generatorset.__contains__ and __contains__ from child classes were
calling into __iter__ to look for values. Since all
previously-encountered values from the generator were cached and checked
in __contains__ before this iteration, __contains__ was effectively
performing iteration busy work which could lead to an explosion of
redundant work.
This patch changes __contains__ to be more intelligent. Instead of
looking at all values via __iter__, __contains__ will instead go
straight to "new" values from the underlying generator.
On a clone of the Firefox repository with around 200,000 changesets,
this patch decreases the execution time of the revset '::(200067)::'
from ~100s to ~4s on the author's machine. Rebase operations (which use
the aforementioned revset), speed up accordingly.
Before this patch, "localrepository.commit()" omits ".hgsubstate" from
"modified" (changes[0]) and "removed" (changes[2]) file list before
checking subrepositories, but leaves one in "added" (changes[1]) as it
is.
Then, "localrepository.commit()" adds ".hgsubstate" into "modified" or
"removed" list forcibly, according to subrepository statuses.
If "added" contains ".hgsubstate", the committed context will contain
two ".hgsubstate" in its "files": one from "added" (not omitted one),
and another from "modified" or "removed" (newly added one).
How many times ".hgsubstate" appears in "files" changes node hash,
even though revision content is same, because node hash calculation
uses the specified "files" directly (without duplication check or so).
This means that node hash of committed revision changes according to
existence of ".hgsubstate" in "added" at "localrepository.commit()".
".hgsubstate" is treated as "added", not only in accidental cases, but
also in the case of "qpush" for the patch adding ".hgsubstate".
This patch omits ".hgsubstate" also from "added" files before checking
subrepositories. This patch also omits ".hgsubstate" exclusion in
"qnew"/"qrefresh" introduced by changeset bbb8109a634f, because this
patch makes them meaningless.
"hg parents --template '{files}\n'" newly added to "test-mq-subrepo.t"
enhances checking unexpected multiple appearances of ".hgsubstate" in
"files" of created/refreshed MQ revisions.
Unknown requirements will now be reported as:
abort: repository requires features unknown to this Mercurial: largefiles!
(see http://mercurial.selenic.com/wiki/MissingRequirement for more information)
Some features of this phrasing:
* avoid double ':' in abort message
* make it more clear who requires and knows what
* don't quote the requirement names - it is not something the user entered or
need the exact spelling of ... and it is "identifiers" that are unambiguous
anyway
* remove double hint by removing "(upgrade Mercurial)" comment
* don't mention upgrading Mercurial without mentioning enabling the feature -
instead, just refer to wiki page for both
* don't just talk about "details", talk about "more information"
The bundle2 now raise value error when seeing invalid parameter names. The first
introduced rules is: no empty parameter.
The test extension is improve to properly abort when ValueError are encountered.
This introduces support for arbitrary characters in stream parameters name and
value. The urlquote format has been chosen because it is:
- simple,
- standard,
- no-op on simple alphanumerical entry.
Parameter can now have a value. We use a `<name>=<value>` form inspired from
capabilities.
There is still no kind of escaping in the name or value, yet.
Stream level parameter have very restricted use case. Clarify why we chosen a
textual format and point that applicative data goes in applicative parts.
Previously, only bookmarks would be considered for blocking a changeset from
being hidden. Now, we also consider non-global tags. This is helpful if we have
local tags that might be hard to find once they are hidden, or tag that are
added by extensions (e.g. hggit or remotebranches).
This changeset introduce an unbundler class to match the bundle2 bundler. It is
currently able to unbundle an empty bundle2 only and will gain more feature at
the same pace than the bundler.
It also comes with its special extension command in test.
This changeset is the very first of a long series. It create a new bundle2
module and add a simple class that generate and empty bundle2 container.
The module is documented with the current state of the implementation. For
information about the final goal you may want to consult the mercurial wiki
page:
http://mercurial.selenic.com/wiki/BundleFormat2
The documentation of the module will be updated with later patches adding more and
more feature to the format.
This patches also introduce a test case. This test case build and use its own
small extension that use the new bundle2 module. Since the new format is unable
to do anything right now, we could not use real mercurial code to test it.
Moreover, some advanced feature of the bundle2 spec will not be used by core
mercurial at all. So we need to have them tested.
If source URL has no path, default destination is resolved as '.'. It is
surprising than useful, and perhaps an unexpected behavior.
This change does not solve issue3880, but can avoid to clone into current
directory by accident.
Previously, if another command was run with --verbose, and for whatever reason
that invoked sshpeer, we'd get a 'running ssh' message from sshpeer. This extra
line would interfere with that command's output and cause dumb parsers to
break.
For example, hg annotate can be run with --verbose to get full usernames. This,
combined with the third-party remotefilelog extension which can cause ssh
connections to be created, leads to an extra 'running ssh' line that breaks
most parsers.
This patch is (BC) because hg pull --verbose will no longer print out exactly
what ssh command it is running.
No tests are affected by this change.
Some extensions set configuration settings that showed up in 'hg showconfig
--debug' with 'none' as source. That was confusing.
Instead, they will now tell which extension they come from.
This change tries to be consistent and specify a source everywhere - also where
it perhaps is less relevant.
Formerly an expression like "2.4-rc::" was tokenized as 2.4|-|rc|::.
This allows dashes in symbols iff the whole symbol-like string can be
looked up. Otherwise, it's tokenized as a series of symbols and
operators.
No attempt is made to accept dashed symbols inside larger symbol-like
string, for instance foo-bar or bar-baz inside foo-bar-baz.
It will help people that need to add capabilities (in a more subtle was that
just adding some to the list) in multiple way:
1. This function returns a list, not a string. Making it easier to look at,
extend or alter the content.
2. The original capabilities function will be store in the dictionary of wire
protocol command. So extension that wrap this function also need to update
the dictionary entry.
Both wrapping and update of the dictionary entry are needed because the
`hello` wire protocol use the function itself. This is specifically sneaky for
extension writer as ssh use the `hello` command while http use the
`capabilities` command.
With this new `_capabilities` function there is one and only one obvious
place to wrap when needed.
This needs to be changed to use a baseset since dagwalker now expects to
receive a smartset. This is basically wrapping revs into a baseset to be
compatible with smartset implementations.
__getitem__ is a method that is not implemented lazily on many of the new
classes and it can be easily replaced with a structure that takes advantage of
the new lazy implementations instead.
__getitem__ is a method that is not implemented lazily on many of the new
classes and it can be easily replaced with a structure that takes advantage of
the new lazy implementations instead.
This classes have no particular order so they rely on python min() and max()
implementation. This methods will be implemented in every smartset class in
future patches. For other classes there are lazy implementations that can be
made for this methods.
When using a different language than English, deprecated options were only
removed from the output of `hg help anycmd` when "DEPRECATED" in the options
description was translated.
This change causes an informative ImportError to be raised when importing
the parsers extension module if the minor version of the currently-running
Python interpreter doesn't match that of the Python used when compiling
the extension module.
This change also exposes a parsers.versionerrortext constant in the
C implementation of the module. Its presence can be used to determine
whether this behavior is present in a version of the module. The value
of the constant is the leading text of the ImportError raised and is set
to "Python minor version mismatch".
Here is an example of what the new error looks like:
Traceback (most recent call last):
File "test.py", line 1, in <module>
import mercurial.parsers
ImportError: Python minor version mismatch: The Mercurial extension
modules were compiled with Python 2.7.6, but Mercurial is currently using
Python with sys.hexversion=33883888: Python 2.5.6
(r256:88840, Nov 18 2012, 05:37:10)
[GCC 4.2.1 Compatible Apple Clang 4.1 ((tags/Apple/clang-421.11.66))]
at: /opt/local/Library/Frameworks/Python.framework/Versions/2.5/Resources/
Python.app/Contents/MacOS/Python
The reason for raising an error in this scenario is that Python's C API
is known not to be compatible from minor version to minor version, even
if sys.api_version is the same. See for example this Python bug report
about incompatibilities between 2.5 and 2.6+:
http://bugs.python.org/issue8118
These incompatibilities can cause Mercurial to break in mysterious,
unforeseen ways. For example, when Mercurial compiled with Python 2.7 was
run with 2.5, the following crash occurred when running "hg status":
http://bz.selenic.com/show_bug.cgi?id=4110
After this crash was fixed, running with Python 2.5 no longer crashes, but
the following puzzling behavior still occurs:
$ hg status
...
File ".../mercurial/changelog.py", line 123, in __init__
revlog.revlog.__init__(self, opener, "00changelog.i")
File ".../mercurial/revlog.py", line 251, in __init__
d = self._io.parseindex(i, self._inline)
File ".../mercurial/revlog.py", line 158, in parseindex
index, cache = parsers.parse_index2(data, inline)
TypeError: data is not a string
which can be reproduced more simply with:
import mercurial.parsers as parsers
parsers.parse_index2("", True)
Both the crash and the TypeError occurred because the Python C API's
PyString_Check() returns the wrong value when the C header files from
Python 2.7 are run with Python 2.5. This is an example of an
incompatibility of the sort mentioned in the Python bug report above.
Failing fast with an informative error message results in a better user
experience in cases like the above. The information in the ImportError
also simplifies troubleshooting for those on Mercurial mailing lists, the
bug tracker, etc.
This patch only adds the version check to parsers.c, which is sufficient
to affect command-line commands like "hg status" and "hg summary".
An idea for a future improvement is to move the version-checking C code
to a more central location, and have it run when importing all
Mercurial extension modules and not just parsers.c.
This change adds to the output of "hg debuginstall" information about the
Python being used by Mercurial. It adds both the path to the Python
executable (i.e. the value of sys.executable) and the version of Python
(specifically the major, minor, and micro versions).
Below is an example of what the output looks like after this change.
The marked lines are the new output lines:
$ hg debuginstall
checking encoding (UTF-8)...
-->showing Python executable (/Users/chris/.virtualenvs/default/bin/python)
-->showing Python version (2.7.6)
checking Python lib (/Users/chris/.virtualenvs/default/lib/python2.7)...
checking installed modules (/Users/chris/mercurial)...
checking templates (/Users/chris/mercurial/templates)...
checking commit editor...
checking username...
no problems detected
Note that we use the word "showing" without an ellipsis for the new lines
because, unlike the other lines (except for "Python lib" which will be
adjusted in a subsequent commit), no check follows the display of this
information.
This methods are intended to duck-type baseset, so we will still have _addset
as a private class but now we can return it without wrapping it into an
orderedlazyset or a lazyset.
These were the last methods to add for smartset compatibility.
This method is intended to duck-type baseset, so we will still have _addset as a
private class but we will be able to return it without wrapping it into an
orderedlazyset or a lazyset.
This method is intended to duck-type baseset, so we will still have _addset as a
private class but now will be able to return it without wrapping it into an
orderedlazyset or a lazyset.
This method is intended to duck-type baseset, so we will still have _addset as a
private class but we will be able to return it without wrapping it into an
orderedlazyset or a lazyset.
This methods are intended to duck-type baseset, so we will still have _addset
as a private class but will be able return it without wrapping it into an
orderedlazyset or a lazyset.
This method is intended to duck-type baseset, so we will still have _addset
as a private class but we will be able return it without wrapping it into an
orderedlazyset or a lazyset.
This methods state if the class is sorted in an ascending or descending order
We need this to implement methods based on order on smartset classes in order
to be able to create new objects with a given order.
We cannot just rely on a simple boolean since unordered set are neither
ascending nor descending.
We need this method to duck-type generatorset since this class is not going to
be used outside revset.py and we don't need to duck-type baseset.
This sort method will only do something when the addset is not already sorted
or is not sorted in the way we want it to be.
If the two collections are in ascending order, yield their values in an
ordered way by iterating both at the same time and picking the values to
yield.
When a spanset was being sorted it didn't take into account it's current
state (ascending or descending) and it reversed itself everytime the reverse
parameter was True.
This is not yet used but it will be as soon as the sort revset is changed to
directly use the structures sort method.
Previously the head() revset would iterate over every item in the subset and
check if it was a head. Since the subset is often the entire repo, this was
slow on large repos. Now we iterate over each item in the head list and check if
it's in the subset, which results in much less work.
hg log -r 'head()' on a large repo:
Before: 0.95s
After: 0.28s
Since this class is only going to be used inside revset.py (it does not duck
type baseset) it needs to duck type only a few more methods for the next
patches.
This class is not supposed to be used outside revset.py since it only
wraps content that is used by baseset typed classes.
It only gets created by revset operations or private methods.
This class is not supposed to be used outside revset.py since it only
wraps content that is used by baseset typed classes.
It only gets created by revset operations or private methods.
This class is not supposed to be used outside revset.py since it only
wraps content that is used by baseset typed classes.
It only gets created by revset operations or private methods.
This class are not supposed to be used outside revset.py since it only
wraps content that is used by baseset typed classes.
It only gets created by revset operations or private methods.
Method needed to propagate sort calls amongst lazy structures.
The generated list (stored in the object) is sorted.
If the generated list did not contain all elements from the generator, we
take care of that before sorting the list.
When a subrepo revision was hidden it was considered missing and mercurial was
unable to update to the corresponding parent revision. Instead warn the user of
the problem and let it choose what to do (the default is to udpate anyway).
This revision has no behaviour change. It simply removes an unnecessary else
that follows an if / return block. The change looks big because a big chunk of
code has been unindented one level.
If a subrepo revision is hidden (because it was amended, for example) it does
not make sense to try to "get" it from the remote subrepository.
Note that in order to avoid making the change look bigger than it is, this adds
an unnecessary else clause. This will be removed on a follow up patch.
Performance Benchmarking:
$ time hg log -qr "0:: and 0:5"
...
real 0m3.665s
user 0m3.364s
sys 0m0.289s
$ time ./hg log -qr "0:: and 0:5"
...
real 0m0.492s
user 0m0.394s
sys 0m0.097s
This will not improve revsets like "::tip" but will do when that gets
intersected or substracted with another revset.
Performance Benchmarking:
$ time hg log -qr "draft() and ::tip"
...
real 0m3.961s
user 0m3.640s
sys 0m0.313s
$ time ./hg log -qr "draft() and ::tip"
...
real 0m1.080s
user 0m0.987s
sys 0m0.083s
When table data contained a newline, the result of minirst.maketable
did not look nice plus it was not recognised by minirst.format:
== === ====
l1 1 one
l2 2 2
22
l3
== === ====
This problem occurred when the description of options had a very long
translation which was split by newlines. Do not bother a translator with
this detail.
The multiline translations for option descriptions have been fixed in
7a88a81d5d9e in it.po, de.po and ro.po. I manually did the same as this patch
does, I removed the newlines.
When a newline was in the description, this created unusable help output:
$ hg help somecommand
hg somecommand [option]...
with somecommand, you can...
options:
== =================== =======================================================
=================================== --longdesc VALUE xxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -n --norm
normal desc --newline VALUE line1 line2 == =================== ===============
===========================================================================
now this looks much nicer:
...
options:
--longdesc VALUE xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
-n --norm normal desc
--newline VALUE line1 line2
Typical use case is to clone repository through command server. Clone may
require user interaction, so command-server protocol is beneficial over
raw stdio channels.
Performance benchmarking:
$ time hg log -qf -l1
...
real 0m1.420s
user 0m1.249s
sys 0m0.167s
$ time ~/local/hg/hg log -qf -l1
...
real 0m0.719s
user 0m0.614s
sys 0m0.103s
Fixes same issue as 3dadbacb6aa4 but now works on Windows too.
With this patch a trailing backward slash won't prevent the extension from
being found on Windows, and we continue to support any combination of forward
and back slashes within the path.
The tests shows no real changes because of this ... but there must be some
weird corner cases where using the right ancestor for the merge planning is
better than using the wrong one.
"hg help" does not state that the code for abort is 255, but it's confusing
to have different code between hg command and command server.
Tests of python-hglib 1.2 passed with this change.
MQ extension will wrap this function to invalidate its state.
repo.invalidate cannot be wrapped for this purpose because qpush obtains
repo.lock in the middle of the operation, triggering repo.invalidate. Also,
it seems wrong to obtain lock earlier because mq data is non-store parts.
This extension has always had correctness issues and has been
unmaintained for years. It is now removed in favor of the third-party
hgwatchman which is maintained and appears to be correct.
Users with inotify enabled in their config files will fall back to
standard status performance.
Adds a only() revset that has two forms:
only(<set>) is equivalent to "::<set> - ::(heads() - heads(<set>::))"
only(<include>,<exclude>) is equivalent to "::<include> - ::<exclude>"
On a large repo, this implementation can process/traverse 50,000 revs in 0.7
seconds, versus 4.2 seconds using "::<include> - ::<exclude>".
This is useful for performing histedits on your branch:
hg histedit -r 'first(only(.))'
Or lifting branch foo off of branch bar:
hg rebase -d @ -s 'only(foo, bar)'
Or a variety of other uses.
This method will replace the creation of lazysets inside the revset methods.
Instead, the classes that handle lazy structures will create them based on
their current order.
transplant command set 'transplant_source' extra for the revision.
Allow an editor to access the extra using HGREVISION environment variable.
This may be useful when an editor is actually a script which modifies a commit
message. Transplant filters is an alternative way to do it.
rebase and graft commands set 'rebase_source' or 'source' extras for the revision.
Allow an editor to access the extras using HGREVISION environment variable.
This may be useful when an editor is actually a script which modifies a commit
message.
The name 'HGREVISION' has been selected as transplant already sets this variable
for its filters (--filter).
We now have a function taking a list and marker and returning an encoded
version. This will allow obsolescence marker exchange experimentation to easily
pushkey-encode markers to be pushed after selection.
$ time hg log -qr "first(0:tip or draft())"
...
real 0m1.032s
user 0m0.841s
sys 0m0.179s
$ time ./hg log -qr "first(0:tip or draft())"
...
real 0m0.378s
user 0m0.291s
sys 0m0.085s
Performance Benchmarking:
$ time hg log -qr "first(author(mpm) or branch(default))"
0:3a6a38229d41
real 0m3.875s
user 0m3.818s
sys 0m0.051s
$ time ./hg log -qr "first(author(mpm) or branch(default))"
0:3a6a38229d41
real 0m0.213s
user 0m0.174s
sys 0m0.038s
The obsstore method now have a return value. This informs caller about the
actual creation of a new markers. No new markers are created if it would have
been a duplicate.
With this small refactoring, the computation of the action to perform and the
actual change to the disk happen in different function. This allows extension to
wrap the later in case of need. The initial motivation is the `remotefilelog`
extension that need to prefetch all the file content to be checked out.
When user type "hg push" command then this patch helps user by
providing hint if no default path is configured.
Second patch is the test coverage, to test the change behaviour of
first patch.
Now log can work in a lazy way and get results as soon as they are processed.
Performance Benchmarking:
$ time hg log -l1 -qr "branch(default)"
0:3a6a38229d41
real 0m2.303s
user 0m2.252s
sys 0m0.048s
$ time ./hg log -l1 -qr "branch(default)"
0:3a6a38229d41
real 0m0.238s
user 0m0.199s
sys 0m0.037s
There is no reason to expose unnecessary Python implementation details and
memory locations, also not in debug mode.
readablefunc was already creating a nice name - we move that functionality
up and reuse it.
We consider having a __call__ and being types.FunctionType sufficiently
similar and unify these two to just using the existing check for __call__.
Close another stream (default stdout, which often is buffered) before writing
to the primary stream (default stderr, which often is unbuffered). The primary
stream is also flushed after writing (in case it is buffered).
This fixes non-deterministic output order, especially on windows.
Originally, the addition of the 'shorten' template function in 83d773060c28
would not consider pure integers for shortening. This patch considers two
simple cases: when the integer starts with zero (which is parsed by Mercurial
as a hash first) and when the integer is larger than the tip (obviously not a
rev).
Instead of using getitem just reverse the revision list and get the first
'lim' elements. With classes like spanset which are easily reversible this
will work faster.
Performance Benchmarking:
$ time hg log -qr "last(all())"
...
real 0m0.569s
user 0m0.447s
sys 0m0.122s
$ time ./hg log -qr "last(all())"
...
real 0m0.215s
user 0m0.150s
sys 0m0.063s
When we add two newlines after ".. note::" translators will not see this
entry. And all versions of docutils interpret this paragraph correctly
(details in 89e31d6e438f).
Emulating POSIX unlink() behavior with os.rename() and os.unlink() is often slow
especially over CIFS from Windows clients due to its protocol overhead. This
patch changes win32.unlink() to try first an exclusive open with the Win32
delete-on-close flag, and if a sharing violation is detected, to fall back to
the original emulation.
This patch also removes a test with os.path.isdir() since we expect opening a
directory shall fail as os.unlink() would.
Example measurements (repeated 3-times after 1-time calibration):
(Without this patch: hg update from null to default)
127 files updated, 0 files merged, 0 files removed, 0 files unresolved
time: real 19.871 secs (user 0.328+0.000 sys 1.794+0.000)
time: real 19.622 secs (user 0.312+0.000 sys 2.044+0.000)
time: real 19.138 secs (user 0.250+0.000 sys 1.872+0.000)
(Without this patch: hg update from default to null)
0 files updated, 0 files merged, 127 files removed, 0 files unresolved
time: real 35.158 secs (user 0.156+0.000 sys 2.512+0.000)
time: real 35.272 secs (user 0.250+0.000 sys 2.512+0.000)
time: real 36.569 secs (user 0.203+0.000 sys 2.387+0.000)
(With this patch: hg update from null to default)
127 files updated, 0 files merged, 0 files removed, 0 files unresolved
time: real 17.893 secs (user 0.328+0.000 sys 1.700+0.000)
time: real 18.512 secs (user 0.265+0.000 sys 1.529+0.000)
time: real 20.238 secs (user 0.312+0.000 sys 1.685+0.000)
(With this patch: hg update from default to null)
0 files updated, 0 files merged, 127 files removed, 0 files unresolved
time: real 12.312 secs (user 0.250+0.000 sys 0.811+0.000)
time: real 12.471 secs (user 0.156+0.000 sys 0.889+0.000)
time: real 9.727 secs (user 0.125+0.000 sys 0.858+0.000)
This adds the keyword 'current' to the template scope when processing a
bookmark list. The 'current' keyword resolves to the name of the currently
active bookmark in the repo. This allows us to apply special labels to the
current bookmark to distinguish it (especially in the case where there are
multiple bookmarks on the same commit).
Example: "{bookmarks % '{bookmark}{ifeq(bookmark, current, \"*\")} '}"
Results in a space separated list of bookmarks where the current bookmark has
an asterix.
Adds a template function that executes a revset and returns the list of
revisions as the result. It has the signature 'revset(query [, args...])'. The
args are optional and are applied to the query string using the standard
python string.format(args) pattern. This allows things like:
'{revset("parents({0})", rev)}' to produce the parents of each individual
commit in the log output. If no args are specified, the revset result is
cached for the duration of the templater; so it's better to not use args if
performance is a concern.
By itself, revset() can be used to print commit parents, print the common
ancestor of a commit with the main branch, etc.
It can be used with the ifcontains() function to do things like
'{ifcontains(rev, revset('.'), label(...), ...)}' to color the working copy
parent, to color certain branches, to color draft commits, etc.
Adds a template function with the signature 'ifcontains(item, set, then[,
else])'. It can be used to do things like '{ifcontains('.hgignore',
file_mods, label(...), ...)}' to color commits that edit the .hgignore file.
A future patch will add the revset() function which will combine with
ifcontains to allow us to color commits if they are in the revset.
The `metadata` argument only allow to specify metadata for all new markers. We
extension the format of the `relations` argument to support optional metadata
argument.
The first user of this should be the evolve extension who want to store parent
information of pruned changeset in extra (until we make a second version of the
format)
The `obsstore` class have a `create` method that create new obsolescence marker
from node. There is another function in the same module `createmarkers`. This
other function is higher level and automatically missing meta data (ultimately
calling the first one)
We add a new comment in the docstring of `obsstore.create` highlighting that
people writing new code probably want to use the top level one.
This situation is not necessarily a problem and do not deserve a warning. It is
just some information that can guide the user in understanding what is going
on.
Making it 'debug' would usually not give the hint when it is relevant so we
make it a 'status' message.
This message frequently caused confusion. "unsynced" is not a well established
user-facing concept in Mercurial and the message was not very specific or
helpful.
Instead, show a message like:
remote has heads on branch 'default' that are not known locally: 6c0482d977a3
This message will also (when relevant) be shown before aborting on "push
creates new remote head".
A similar (but actually very different) message was addressed in cbd5a12a601a.
We extract the `tryone` function into the `cmdutil` module. A lot of the command
context have to be passed to the utility function, but having and explicit
declaration will allow extension to wrap it. This will allows use to make
changeset evolution related experiment in dedicated extension.
Improving the API of this function is noble goal but outside of the scope of
this patches.
A missing ancestor expression is any expression of the form (::x - ::y) or
equivalent. Such expressions are remarkably common, and so far have involved
multiple walks down the DAG, followed by a set difference operation.
With this patch, such expressions will be transformed into uses of the fast
algorithm at ancestor.missingancestor.
For a repository with over 600,000 revisions, perfrevset for '::tip - ::-10000'
returns:
Before: ! wall 3.999575 comb 4.000000 user 3.910000 sys 0.090000 (best of 3)
After: ! wall 0.132423 comb 0.130000 user 0.130000 sys 0.000000 (best of 75)
pull: move changeset pulling in its own function
Now that every necessary information is held in the `pulloperation` object, we
can finally extract the changeset pulling to it's own function.
This changeset is pure code movement only.
Tree discovey use a `fetch` variable to know what is being pulled. We move this
information in the `pulloperation` object. This make it possible to extract the
changeset pulling logic into its own function.
The computation of the subset is simple operation using two useful pull
information (1) the set of common changeset before the pull (2) the set of
pulled changeset. We move this data into the `pulloperation` object since some
phase will need them. And we turn the pulled subset computation behind a
property case as multiple pull phase will need it.
Now that every necessary information is held in the `pulloperation` object, we
can finally extract the phase synchronisation phase to it's own function.
This changeset is pure code movement only.
We compute the set of local changeset that were target of the pull. This is then
used by phases logic to decide which part of the history should have it phase
updated.
We move this information into the object to allow extraction of phase
synchronisation in its own function.
I expect obsolete marker exchange to use it too in the future.
Most local change that occurs during a pull are doing within a `transaction`.
Currently this mean (1) adding new changeset (2) adding obsolescence markers. We
want the two operations to be done in the same transaction. However we do not
want to create a transaction if nothing is added to the repo. Creating an empty
transaction would drop the previous transaction data and confuse tool and people
who are still using rollback.
So the current pull code has some logic to create and handle this transaction on
demand. We are moving this logic in to the `pulloperation` object itself to
simplify this lazy creation logic through all different par of the push.
Note that, in the future, other part of pull (phases, bookmark) will probably
want to be part of the transaction too.
The obsolescence marker exchange code was already extracted during a previous
cycle. We are moving the extracted functio in this module. This function will
read and write data in the `pulloperation` object and I prefer to have all core
function collaborating through this object in the same place.
This changeset is pure code movement only. Code change for direct consumption of
the `pulloperation` object will come later.
This object will hold all data and state gathered through the pull. This will
allow us to split the long function into multiple small one. Smaller function
will be easier to maintains and wrap. The idea is to blindly store all
information related to the pull in this object so that each step and extension
can use them if necessary.
We start by putting the `repo` variable in the object. More migration in other
function.
