This object will hold all data and state gathered through the push. 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 push 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
changeset.
The localrepo class if far too big. Push and pull logic will be extracted and
reworked to better fit with the fact they now exchange more than plain changeset
bundle.
This changeset extract the push code. later changeset will slowly slice this
over 200 hundred lines and 8 indentation level function into smaller saner
brick.
The localrepo.push method is kept for now to limit impact on user code. But it
will be ultimately removed, now that the public supposed API is hold by peer.
Now that discovery is working on unfiltered changeset, I had a good occasion to
look at that bug again. This let me realise that a trivial node vs rev
comparision was the cause of this two years old bugs…
Happy second birthday phases!
Running `hg log --style compact` (or any other style) raised a traceback when
no template directory was there. Now there is a message:
Abort: style 'compact' not found
(available styles: no templates found, try `hg debuginstall` for more info)
There is no test because this would require to rename the template directory.
But this would influence other tests running in parallel. And when the test
would be aborted the wrong named directory would remain, especially a problem
when running with -l.
test-gpg.t left the random_seed file as modified. That was slightly confusing
... and it was accidentally changed in 7e8ce69e784d.
The seed is created on demand and there is no reason to track it. There is also
no reason to leak state between test runs so we let the test clean up after
running.
It looks like somewhere down the line, patch.diffopts changed the
names of the options that it recognises, but record.recordfunc wasn't
updated to the new names. Instead of trying to write down names at
all, we now use whatever names are provided in commands.diffwsopts and
pass that along to patch.diffopts, along with a couple of custom
options
The record extension is writing its own version of commands.diffwsopts
which is identical to commands.diffwsopts. Based on the principle that
code duplication increases maintenance burden, this patch removes
record's ad-hoc diffopts in favour of commands.diffwsopts
The German translation for "remote" as "entfernt" can be misleading
in situations where remote is used as a noun. "entfernt" is not a
noun and can also mean "removed". To clarify this we rename "remote"
to "Gegenseite" when used as a noun.
parse() cannot be called at the same time because a parser object keeps its
states. This is no problem for command-line hg client, but it would cause
strange errors in multi-threaded hgweb.
Creating parser object is not too expensive.
original:
% python -m timeit -s 'from mercurial import revset' 'revset.parse("0::tip")'
100000 loops, best of 3: 11.3 usec per loop
thread-safe:
% python -m timeit -s 'from mercurial import revset' 'revset.parse("0::tip")'
100000 loops, best of 3: 13.1 usec per loop
As tags may have embedded spaces, and "hg tags" command doesn't escape them,
the output of the command doesn't make a well-formed list, so we can't just
iterate over it. Instead, apply a simple regexp to transform it to a list
which we actually use. Line boundary matching should be enabled.
Existing tool like "msgfmt --check" can check typical translation
problems (missing "%s" in msgstr, for example), but can't check
Mercurial specific ones.
For example, "msgfmt --check" can't check whether the translated
string given to "ui.promptchoice()" is correct or not, even though
problems like below cause run-time error or unexpected behavior:
- less or more choices than msgid,
- choices without '&', or
- choices with '&' followed by none
This patch adds the tool to check Mercurial specific translation
problems in *.po files.
Previously, unshelve would temporarily commit unknown files (via addremove) in
an attempt to allow unshelving into unknown files. This produced unexpected
results, like the file time stamp changing and a .i file being created.
This change makes it no longer use addremove. It ignores unknown files
completely. If an unshelve would overwrite an unknown file, the unknown file is
moved to *.orig
The shelve continue/abort format is changed, but it just removes stuff from the
end of the file, so it can still read the old format.
a8386b4c47b1 introduced splitstandin on all action filenames. It would however
crash on 'd' actions where the filename is None.
Fix that and add test coverage for that case.
Passing a non-string to parsers.parse_index2() causes Mercurial to crash
instead of raising a TypeError (found on Mac OS X 10.8.5, Python 2.7.6):
import mercurial.parsers as parsers
parsers.parse_index2(0, 0)
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 parsers.so 0x000000010e071c59 _index_clearcaches + 73 (parsers.c:644)
1 parsers.so 0x000000010e06f2d5 index_dealloc + 21 (parsers.c:1767)
2 parsers.so 0x000000010e074e3b parse_index2 + 347 (parsers.c:1891)
3 org.python.python 0x000000010dda8b17 PyEval_EvalFrameEx + 9911
This happens because when arguments of the wrong type are passed to
parsers.parse_index2(), indexType's initialization function index_init() in
parsers.c leaves the indexObject instance in a state that indexType's
destructor function index_dealloc() cannot handle.
This patch moves enough of the indexObject initialization code inside
index_init() from after the argument validation code to before it.
This way, when bad arguments are passed to index_init(), the destructor
doesn't crash and the existing code to raise a TypeError works. This
patch also adds a test to check that a TypeError is raised.
For technical reason (discovery, obsolescence marker) the hash of secret
changeset are communicated outside of your repo. We clarifie that in the help so
that people does not used hash of secret changeset as nuclear launch code.
The largefile hashes are mostly an implementation detail, but they are "leaked"
in several places anyway, and showing the hashes is better than not giving the
user any information about the options in the prompt.
The hashes are long, but it is largefile hashes and it would thus be confusing
to shorten them.
Before it tried to explain the exact situation when merging moved largefiles.
That do not happen for normal merges and is not more relevant for largefiles
than for normal files. It is unneeded complexity - remove it.
