Using bundle2 for exchange unlock the usage of changegroup version 2. This
version of the changegroup held more information (delta base) that result in a
small increase in content size.
It also lead to reordering of output because the exchange scheduling is a bit
different.
Using bundle2 for exchange unlocks the usage of changegroup version 2. This
version of the changegroup held more information (delta base) that result in
a small increase in content size (20 bytes x 2 changes).
The bundle2 version of obsmarkers exchange is more informative. Switching to
bundle2 by default will change the output of this tests. To reduce the noise
when switching bundle2 to the default protocol, we migrate this tests early.
Today, the terms 'active' and 'current' are interchangeably used throughout the
codebase in reference to the active bookmark (the bookmark that will be updated
with the next commit). This leads to confusion among developers and users.
This patch is part of a series to standardize the usage to 'active' throughout
the mercurial codebase and user interface.
Today, the terms 'active' and 'current' are interchangeably used throughout the
codebase in reference to the active bookmark (the bookmark that will be updated
with the next commit). This leads to confusion among developers and users.
This patch is part of a series to standardize the usage to 'active' throughout
the mercurial codebase and user interface.
Retain old label as well for backwards compatibility.
Today, the terms 'active' and 'current' are interchangeably used throughout the
codebase in reference to the active bookmark (the bookmark that will be updated
with the next commit). This leads to confusion among developers and users.
This patch is part of a series to standardize the usage to 'active' throughout
the mercurial codebase and user interface.
The tested feature was added to multiple hgweb styles in 5c045b277096, but only
paper was tested. Let's test everything now, including monoblue, which only got
the feature some 6 years late in d00ca9ba77dc.
The comment came together with the whole test file and the feature (descend
empty dirs in hgweb) in 5c045b277096, but for some reason wasn't exactly
accurate.
Namely, there isn't e1 directory in the test at all, it obviously should say
d1; and b1 didn't terminate at level 3, but does now.
As seen in issue4565 and issue4624, GUI wrappers and automated scripts are
likely to generate a long query that just has numeric revisions joined by 'or'.
One reason why is that they allows users to choose arbitrary revisions from
a list. Because this use case isn't handled well by smartset, let's optimize
it to a plain old list.
Benchmarks:
1) reduce nesting of chained 'or' operations
2) optimize to a list (this patch)
revset #0: 0 + 1 + 2 + ... + 1000
1) wall 0.483341 comb 0.480000 user 0.480000 sys 0.000000 (best of 20)
2) wall 0.025393 comb 0.020000 user 0.020000 sys 0.000000 (best of 107)
revset #1: sort(0 + 1 + 2 + ... + 1000)
1) wall 0.035240 comb 0.040000 user 0.040000 sys 0.000000 (best of 100)
2) wall 0.026432 comb 0.030000 user 0.030000 sys 0.000000 (best of 102)
revset #2: first(0 + 1 + 2 + ... + 1000)
1) wall 0.028949 comb 0.030000 user 0.030000 sys 0.000000 (best of 100)
2) wall 0.025503 comb 0.030000 user 0.030000 sys 0.000000 (best of 106)
This is the same workaround introduced at 3aa0e4733e6f. Without this patch,
"null or x" can't be optimized to _list(null x).
Test case will be added by the next patch.
This allows us to optimize chained 'or' operations to _list() expression.
Unlike _intlist() or _hexlist(), it's difficult to remove duplicates by the
caller of _list() because different symbols can point to the same revision.
If the caller knows all symbols are unique, that probably means revisions or
nodes are known, therefore, _intlist() or _hexlist() should be used instead.
So, it makes sense to check duplicates by _list() function.
'%ls' is no longer used in core, this won't cause performance regression.
This is a useful information to have in general and we already have debug
output related to listkeys. I'm planning to play around with massive amount of
phases roots and bookmarks so having this data in debug will be very useful.
This already got me to spot that one of the Logilab's review repo is exchanging
65KB of phases data during each exchanges.
We are doing some strange special casing of phase push when:
- the source is a subrepo
- the destination is publishing
- some changeset are still draft on the destination
In that case we do not push phases information (to publish the draft changesets)
because it could break simple cycle of 'clone/pull/push' of subrepos. We have to
detect this case earlier to have bundle2 respecting it.
We change the test to check the behavior for both bundle1 and bundle2.
The old output is very verbose and unsuitable for general debug level. It is
however very useful for debugging bundle2 generation or consumption issues. All
this verbose ouput is hidden under a 'devel.bundle2.debug' flag.
Something in Python 2.7.9 or so broke the --debugger option with
ui.debugger = ipdb. I get the traceback below. There is some apparent
confusion with demandimport. This should be disabled anyway for the
--debugger option. The debugger must be imported right away, before
any other dispatch. There's no benefit in delaying the debugger
import.
This patch uses the demandimport.deactivated() context manager.
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 121, in _runcatch
debugmod = __import__(debugger)
File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 115, in _demandimport
return _hgextimport(_import, name, globals, locals, fromlist, level)
File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 47, in _hgextimport
return importfunc(name, globals, *args)
File "/usr/lib/python2.7/dist-packages/ipdb/__init__.py", line 16, in <module>
from ipdb.__main__ import set_trace, post_mortem, pm, run, runcall, runeval, launch_ipdb_on_exception
File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 134, in _demandimport
mod = _hgextimport(_origimport, name, globals, locals)
File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 47, in _hgextimport
return importfunc(name, globals, *args)
File "/usr/lib/python2.7/dist-packages/ipdb/__main__.py", line 29, in <module>
if IPython.__version__ > '0.10.2':
File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 106, in __getattribute__
self._load()
File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 78, in _load
mod = _hgextimport(_import, head, globals, locals, None, level)
File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 47, in _hgextimport
return importfunc(name, globals, *args)
File "/usr/lib/python2.7/dist-packages/IPython/__init__.py", line 45, in <module>
from .config.loader import Config
File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 132, in _demandimport
return _origimport(name, globals, locals, fromlist, level)
File "/usr/lib/python2.7/dist-packages/IPython/config/__init__.py", line 16, in <module>
from .application import *
File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 115, in _demandimport
return _hgextimport(_import, name, globals, locals, fromlist, level)
File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 47, in _hgextimport
return importfunc(name, globals, *args)
File "/usr/lib/python2.7/dist-packages/IPython/config/application.py", line 30, in <module>
from IPython.external.decorator import decorator
File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 134, in _demandimport
mod = _hgextimport(_origimport, name, globals, locals)
File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 47, in _hgextimport
return importfunc(name, globals, *args)
File "/usr/lib/python2.7/dist-packages/IPython/external/decorator/__init__.py", line 2, in <module>
from decorator import *
File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 115, in _demandimport
return _hgextimport(_import, name, globals, locals, fromlist, level)
File "/usr/lib/python2.7/dist-packages/mercurial/demandimport.py", line 47, in _hgextimport
return importfunc(name, globals, *args)
File "/usr/lib/python2.7/dist-packages/decorator.py", line 240, in <module>
'ContextManager', (_GeneratorContextManager,), dict(__call__=__call__))
This seems like a textbook case for the new demandimport.deactivated
context manager: check if something must be done, do it, and cleanup
at the end regardless of exceptions.
The diff isn't as bad as it seems. It's just all the whitespace
changes due to needing an extra level of indentation. It looks cleaner
with `hg diff -w`.
The logic in the convert extension is more advanced, supporting extra features
like converting revision IDs in 'extras' (e.g. 'amend_source'), supports
updating hashes in commit messages, and outputs an SHA map file. Rather than
try to duplicate all of that, just use the existing code.
Even though the convert extension supports user supplied options like filemap,
etc, those features aren't available on the lfconvert interface. Therefore, it
is safe to use the filemap mechanism (in memory) to handle the standin -> file
rename. The convert extension handles the destination locking for this path.
There was a comment in test-lfconvert.t about the hash on rev 5 being different
because it was doing a better job than "hg remove" + "hg merge" + "hg commit".
It isn't clear to me what was happening or why, but now the hashes match the
original repo exactly after a roundtrip, which seems like a good idea. If there
really was something beneficial about the previous behavior, perhaps merge can
be changed so that everyone benefits.
Converting to a largefiles repo still uses the original (limited) lfconvert
logic.
The part generation process was lacking a ui object and could not produce debug
output. It seems valuable to have some debug output on this part too, especially
now that we are planning to be able to hide it in the default --debug output.
The bundling process is very verbose, we would like to be able to hide such
output behind a configuration flag and have it more explicitly referencing
bundle2. The first step is to gather all these messages in a dedicated function.
Mercurial uses tags of null to mark deletions, but convert was
silently discarding these because it had no mapping for them. Thus, it
was resurrecting deleted tags.
The bundling process is very verbose, we would like to be able to hide such
output behind a configuration flag and have it more explicitly referencing
bundle2. The first step is to gather all these messages in a dedicated
function.
The same gathering will be later do for debug message issue by unbundling.
We recently simplified the code computing the heads of a repo. This patch uses
the same simplification for phase computation. We use index_get_parents instead
of replicating its code.
index_get_parents needs to be used in the phase computation code so we need
to move its declaration higher to be able to call it. It cannot be moved any
higher than that so we won't have any more patch doing the same thing.
This patch is part of a series of patches to change the recording ui to reflect
the operation currently running (commit, shelve, revert ...).
This patch adds a new argument to the recording function to reflect in the UI
what operation we are running.
The fix in a795188178a1 is actually wrong. We now use the filename to match what
'_addentry'. This whole untested code is quite suspicious. This seems to point
that no one is ever running 'tr.find' for a backup file.
checkcopies was using fctx.rev() which it was expecting would be
equivalent to linkrev() but was triggering the new _adjustlinkrev path.
This was making grafts and merges with large sets of potential copies
very expensive.
Before this patch, hook argument `txnid` isn't passed to `pretxnopen`
hooks, even though `hooks` section of `hg help config` describes so.
``pretxnopen``
Run before any new repository transaction is open. The reason for the
transaction will be in ``$HG_TXNNAME`` and a unique identifier for the
transaction will be in ``HG_TXNID``. A non-zero status will prevent the
transaction from being opened.
Before this patch, transaction ID (TXNID) is calculated from
`transaction` object itself by `id()`, but this prevents TXNID from
being passed to `pretxnopen` hooks, which should be executed before
starting transaction processing (also any preparations for it, like
writing journal files out).
As a preparation for passing TXNID to `pretxnopen` hooks, this patch
separates calculation of TXNID from creation of `transaction` object.
This patch uses "random" library for reasonable unique ID. "uuid"
library can't be used, because it was introduced since Python 2.5 and
isn't suitable for Mercurial 3.4.x stable line.
`%f` formatting for `random.random()` is used with explicit precision
number 40, because default precision for `%f` is 6. 40 should be long
enough, even if 10**9 transactions are executed in a short time (a
second or less).
On the other hand, `time.time()` is used to ensures uniqueness of
TXNID in a long time, for safety.
BTW, platform not providing `/dev/urandom` or so may cause failure of
`import random` itself with some Python versions (see Python
issue15340 for detail http://bugs.python.org/issue15340).
But this patch uses "random" without any workaround, because:
- "random" is already used directly in some code paths,
- such platforms are very rare (e.g. Tru64 and HPUX), and
http://bugs.python.org/issue15340#msg170000
- updating Python runtime can avoid this issue
This fixes the crash caused by "branch(null)" revset. No cache should be
necessary for nullrev because changelog.branchinfo(nullrev) does not involve
IO operation.
Note that the problem of "branch(wdir())" isn't addressed by this patch.
"wdir()" will raise TypeError in many places because of None. This is the
reason why "wdir()" is still experimental.
