Before this changeset, navigation generation crashed if revision "0" was
filtered. We introduce a `_first` methods on revision navigation that return the
lowest unfiltered element and use it in two place were the "0" changeset was
explicitly referenced.
Test case are introduced.
For some obscure reason, changelog.node(0) returns nullid if changelog is empty.
this break empty navigation detection. We fix this code by using the length of
the changelog.
Using the length have some issue with revision filtering but this is a small
step in the right direction. Proper fix comes in later changeset.
test-dirstate.t fails on AIX in the absurd date test. AIX touch errors on
any date prior to 1970. AIX mktime() gives an error on such dates, so the
problem is deeper than touch and attempts to work around touch in Python
failed.
Give up. Add an AIX test to hghave and skip the absurd date test on AIX.
Before this patch, "hg.bat" for Windows environment always uses
"%~dp0..\python" as explicit path to "python.exe".
This path may not be valid in some cases.
For example, on the environment using "virtualenv" python package,
both "python.exe" and "hg.bat" are placed in the same directory. In
this case, "python.exe" should be found on PATH, because virtualenv
activation script puts "python.exe" on the PATH.
This patch uses explicit path to "python.exe" only if it exists, and
expects that "python.exe" can be found on PATH otherwise.
After 08202d1ef738 I see:
$ hg id -q
largefiles: repo method 'commit' appears to have already been wrapped by another extension: largefiles may behave incorrectly
largefiles: repo method 'push' appears to have already been wrapped by another extension: largefiles may behave incorrectly
3bd0c95ec1bf
The warning is bad:
* The message gives no hint what the problem is and how it can be resolved.
The message is useless.
* Largefiles do have its share of problems, but I don't think I ever have seen
a problem where this warning would have helped. The 'may' in the warning
seems like an exaggeration of the risk. Having largefiles enabled in
combination with for instance mq, hggit and hgsubversion causes a warning
(depending on the configuration order) but do not cause problems. Extensions
might of course be incompatible, but they can be that in many other ways.
The check and the message are incorrect.
It would thus be better to remove the check and the warning completely.
Before 08202d1ef738 the check always failed. That change made the check work
more like intended ... but the intention was wrong. This change will thus also
back that change out.
Before this patch, "%unset" can't unset values defined in the other
files read in previously, even though online help document says that
it can. It can unset only values defined in the same configuration
file.
For example, the value defined in "~/.hgrc" can't be unset by "%unset"
in ".hg/hgrc" of the repository.
This patch records "%unset"-ed values in "config.parse()", and
discards corresponding values in "config.update()".
Before this patch, there is no test script testing configuration
handling generally. "test-config-case.t" seems to be specific for
testing case sensitive configuration.
This patch renames from "test-config-case.t" to "test-config.t" for
centralization of tests around configuration handling.
Before this patch, the prompt text for asking password is directly
passed to "getpass.getpass()" of Python standard library.
In "getpass.getpass()" implementation on Windows environment, the
prompt text is split into byte sequence and "msvcrt.putch()" is
applied on each bytes in it. This splitting causes non-ASCII prompt
text to be broken.
This patch shows the prompt text for asking password on "ui.getpass()"
side, and invokes "getpass.getpass()" with empty prompt text. This
prevents non-ASCII prompt text from being broken in
"getpass.getpass()" implementation.
This patch also sets "ui.prompt" label to prompt text to follow
"ui.prompt()" style.
The regular expression was meant to match cases where an 'i' command was
not followed by precisely a '\' and then a newline; it failed to match
the newline, so cases with a '\' but no newline would erroneously pass.
The windows and vfat test runs were failing due to read/write permissions not
working the same on those systems. On vfat, permissions can't be changed
at all, and on windows it seems the chmod emulation doesn't remove read
permissions. We could theoretically get the 'cannot write to blacklog.log'
test to pass on windows but there's no #if condition to let us exclude vfat
only.
Verified that test-blackbox passes on windows now.
Expands the rule added in a3f00ef2b622 to include cases where the
address is a line number instead of a regular expression, and fixes an
instance of this pattern in test-unionrepo.t.
BSD sed requires the 'i' command to be followed with a backslash and a
newline, like so:
$ sed -e '/^@/i\
> other'
We've encountered this problem before, e.g. in test-mq.t (215a8789129e).
This change adds a check-code rule and fixes two instances of the
problem in test-record.t.
Previously, colorui assumed that it would only be called when mode wasn't
None. 255b770b2eff changed that, so now colorui needs to care about whether it
should colorize output.
If enabled, log rotation prevents the amount of space used by the
blackbox log from growing without bound. This becomes important in
cases where there are a lot of busy repositories managed by humans
and automation on many machines.
In large deployments, we cannot reasonably track all the repos where
blackbox logs need to be managed, so it is safer to have blackbox
manage its own logs than to move responsibility to an external tool
such as logrotate.
This change adds two configuration keys:
* blackbox.maxsize is the maximum allowable size of the current log
* blackbox.maxfiles is the number of log files to maintain
This accepts a floating point number, followed by optional whitespace,
followed by an optional one- or two-letter unit specifier (for
bytes, kilobytes, megabytes, or gigabytes).
Previously only the class of repo.ui was set. The class was set in the wrapper
of dispatch._runcommand. But this is called after the repo is created. Only
the class of repo.ui is set because repo.baseui already exists and is not
accessible.
We now set the class in uisetup because this is called before repo creation.
This is also the place suggested in the wiki for modifying classes.
gcc 4.6.3 on 12.04 Ubuntu machine emits warnings:
mercurial/parsers.c: In function ‘find_deepest’:
mercurial/parsers.c:1288:9: warning: format ‘%ld’ expects argument of type
‘long int’, but argument 3 has type ‘Py_ssize_t’ [-Wformat]
mercurial/parsers.c:1288:9: warning: format ‘%ld’ expects argument of type
‘long int’, but argument 4 has type ‘Py_ssize_t’ [-Wformat]
Before this patch, refcount (managed in "needed") of the annotation
result is kept as 1, even if corresponding annotation result is
discarded from "hist", because it isn't decreased and discarded.
In the history tree including merging revision, the most recent common
ancestor of merged revisions is scanned twice. Refcount of such
ancestor never becomes 0, because refcount is started from 1 at the
second scanning.
This prevents annotation results of merging revision in "hist" from
being discarded, and decreases memory efficiency.
This patch discards refcount of the annotation result, when the
corresponding annotation is discarded from "hist".
This allows using a template keyword on calls to the sub function and brings
the function inline with most other semantics of the other template functions.
Having a dedicated function will allow us to experiment with other exchange
strategies in an extension. As we have no solid clues about how to do it right,
being able to experiment is vital.
Some transaction tricks are necessary for pull. But nothing too scary.
Having a dedicated function will allows us to experiment with other exchange
strategies in an extension. As we have no solid clues about how to do it right,
being able to experiment is vital.
I intended a more ambitious extraction of push logic, but we are far too
advanced in the release cycle for it.
Before this patch, port 25 (wellknown port of SMTP) is used as default
port, even if "[smtp] tls" is configured as "smtps".
This patch uses port 465 (wellknown port of SMTPS) as default port, if
"[smtp] tls" is configured as "smtps".
The test didn't break when I originally committed it (git version
1.7.12.4 (Apple Git-37)), and still doesn't on that machine, but the
output changes elsewhere with "Warning: you are leaving N commits
behind..."
This change sets a ref on the commit we're updating the subrepo _away_
from to quash the warning.
Now that we explicitly detect duplicated changesets, we can explicitly
detect missing ones. We cover the same cases as before, some others
and we offer a better error message in all cases.
Before this change one would issue rules with duplicated entries. For
this to happen some other changeset had to be missing to maintain the
rules length.
