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.
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.
Up until now commit/backout `--logfile` option was completed only with
*.txt-files. This requirement is a bit too strong (and is nowhere to be stated)
so it's better to complete with all files.
Stolen from zsh.git repo, c5fce37b changeset by Oliver Kiddle.
Add -o $output.
When using Meld as intended (merge from left and right into the center panel),
the merged version is written to the wrong file without this option ($base,
a temporary file, which is ignored by Mercurial).
Add meld.check=changed as a secondary safety net.
Use `debuglabelcomplete` command when populating labels list, instead of
calling `hg` three times: for branches, bookmarks and tags. Do not pass string
being completed to `hg debuglabelcomplete` (as `$words[$CURRENT]`), since it
breaks `_hg_revrange` completion (`--rev 2.5:2.5.<Tab>`) for no apparent
benefit.
Also complete `hg view` with labels, not just tags, and drop unused `_hg_tags`.
As suggested by mpm reintroducing this test failure on windows is
prevented by a code-check. One line in a unix test is ignored.
This pattern matches 20 windows glob lines.
We explicitly redraw before echoing the message so that it simply
displays at the bottom of the window. Also simplifies the message
printing by using 'echomsg' (which uses 'echohl' internally) and adds
the names of the software involved for improved Googleability.
Adds a message displayed at each vimdiff invocation:
merge conflict detected, type ":cq" to abort
Vimdiff is very confusing for non-vim user (not to speak about vim user confused
anyway. However it is very likely that vimdiff is picked as the mergetool of
choice when using the default config:
- vim is available on all UNIX system.
- Its one of the rare non graphical merge tools.
It seems like the API has changed somewhere around 8.5.7, so the preferred way
of getting the current theme is now [ttk::style theme use], while the
deprecated (but still working) is $::ttk::currentTheme.
As when hg tags is being called without -v option, it returns
lines with two elements in each, we can just interate them as
if it were a usual Tcl list using foreach and two variables.
Line endings and whitespace don't matter when doing so, so we
may keep them as is.
When we're processing the lines, tag variable is assigned a tag
name, and rev is a string in form of revision:hash which we can
split on colon. As Tcl8.4 lacks lassign command, and using lindex
makes code a bit less readable, we use foreach to iterate over
two-element list.
Replace labels with window titles.
That also requires to change grid placement manager settings
to compensate padding which used to be applied to now non-existent
labels.
Ttk doesn't automatically set up Tk colour palette.
Because of that, Ttk controls look differently when used
together with old Tk controls. When we use Ttk controls,
we first query if we have any setting for the client
background, and if we do, we update Tk palette as well.
The current bash_completion code can be very slow in a large working
directory. It always uses "hg status" to generate possibly matching
files, which checks the status of every file. We often don't care
about status when completing, so that cost is very high.
As the new debugpathcomplete command does not check the status of
files, it offers much better performance for commands that only
care about completing names.
When completing a "label" (a symbolic name for a commit), the
bash_completion script currently has to invoke hg three times. For
a large repository, the cost of starting up and loading all the
necessary context over and over is very high.
For instance, in mozilla-central:
time (export HGPLAIN=1; hg tags -q; hg bookmarks -q; hg branches) >/dev/null
0.446 sec
Compare with the debuglabelcomplete command that this commit adds:
time hg debuglabelcomplete >/dev/null
0.148 sec
This greatly helps responsiveness.
Previously, we only completed files that had already been manually
deleted. That behaviour made no sense. We now complete unmodified,
modified, and deleted files.
This greatly helps completion performance for most commands that deal
with files.
In a working dir with 150,000 files, where we want to complete the name
of a modified file under a path beginning with "a", from the root of
the working dir:
(old) hg status -nm . 1.7 sec
(new) hg status -nm "glob:a**" 0.3
Even "hg add" becomes a little faster, in spite of being the worst
case (matching untracked files).
We explicitly redraw before echoing the message so that it simply
displays at the bottom of the window. Also simplifies the message
printing by using 'echomsg' (which uses 'echohl' internally) and adds
the names of the software involved for improved Googleability.
Adds a message displayed at each vimdiff invocation:
merge conflict detected, type ":cq" to abort
Vimdiff is very confusing for non-vim user (not to speak about vim user confused
anyway. However it is very likely that vimdiff is picked as the mergetool of
choice when using the default config:
- vim is available on all UNIX system.
- Its one of the rare non graphical merge tools.
We have a bunch of tests that still use
kill `cat hg.pid`
or worse,
kill `cat hg.pid`; while kill -0 `cat hg.pid`; sleep 0; done
Cleaning these up to use tests/killdaemons.py is non-trivial, so for now
we just add a warning.
These settings were replaced by check=changed and check=conflicts in
9b0e7e973592. There is no reason to announce two different ways to achieve the
same. The old way should be kept but not announced.
This also makes the perfancestorset command use lazy membership testing. In a
linear repository with over 400,000 commits, without this patch, hg
perfancestorset takes 0.80 seconds no matter how far behind we're looking.
With this patch, hg perfancestorset -- X takes:
Rev X Time
-1 0.00s
-4000 0.01s
-20000 0.04s
-80000 0.17s
-200000 0.43s
-300000 0.69s
0 0.88s
Thus, for revisions close to tip, we're up to several orders of magnitude
faster. At 0 we're around 10% slower.
The new command, perfancestorset, takes an argument denoting which revset to
test the membership of.
Currently this runs through all the ancestors and converts them into a set.
The primary purpose of having this is to compare this approach, currently used
in several places, against the upcoming lazy approach.
New warnings:
> a.b=ab
missing whitespace in assignment
(the pattern did not accept '.' on the left hand side)
> a=a
missing whitespace in assignment
(the right hand side pattern never matched a single character)
> a=a + 7
missing whitespace in assignment
(the pattern only matched one character after the identifier following =)
The check pattern only checked for whitespace between keyword and operator.
Now it also warns:
> x = f(),7
missing whitespace after ,
> x = f()+7
missing whitespace in expression
When status needs to look at unknown files (e.g. when running hg status), it
needs to use a completely different algorithm than when it doesn't (e.g. when
running hg diff).
This makes sure that .hg/requires is observed and the correct kind of store
object is created. Otherwise we might mutilate our test repos when experimenting
with new repo formats.
This adds two new commands:
- analyze examines an existing repo and writes out a statistical
description of its properties that contains no identifying
information.
- synthesize creates new commits based on the description generated
by analyze.
The intention is that a repo constructed using synthesize will have
properties that are vaguely statistically similar to the originating
repo, but entirely random content.
This can be useful for forecasting performance as a repo grows, and
for developers who want to find bottlenecks in proprietary repos
to which they do not have access.
Heredocs are usually fed to other commands and
shouldn't follow the standard conventions of shell
commands.
This restores the old behaviour of how heredocs
were handled in old-style test files.
This makes it possible to do lock validation as part of a normal test
run. I didn't attempt any wlock validation because that's a bit more
subtle to detect properly. Thanks to the initial patch from Mads for
the idea.
Examples (all done with somewhat dated clones I found on my disk):
Netbeans (~120k entries in fncache):
$ hg perffncacheencode
! wall 4.338000 comb 4.336828 user 4.336828 sys 0.000000 (best of 3)
Openoffice (~77k entries in fncache)):
$ hg perffncacheencode
! wall 1.533000 comb 1.528810 user 1.528810 sys 0.000000 (best of 7)
Xen (~10k entries in fncache):
$ hg perffncacheencode
! wall 0.198000 comb 0.187201 user 0.187201 sys 0.000000 (best of 51)
Done on Windows 7 x64.
The standard reaction in from of unexpected vimdiff is to ":quit". This will
make vimdiff return a 0 status even if no merge were done at all.
This change detect that nothing have been changed in vimdiff as a potential
unresolved conflict.
The tests in test-annotate.t and test-import-git.t that relied on trailing
space in a file created by a here string is now masked by a literal 'EOL'
string that is removed.
The test used 'echo' to test '!' style aliases. On Windows 'echo' is handled
by cmd and thus behaves very differently from the 'normal' echo command.
The simple workaround used here for using the same alias on all platforms
is to use 'printf' instead. Msys 'printf' will also handle sh quoting and
escaping in cmd.
Environment variable expansion with sh syntax is handled by launching sh.
Accepting a variable number of arguments as the old API did is
deeply ugly, particularly as it means the API can't be extended
with new arguments. Partly as a result, we have at least three
different implementations of the same ancestors algorithm (!?).
Most callers were forced to call ancestors(*somelist), adding to
both inefficiency and ugliness.
Allows you to restrict a ssh key to have read-only access to a set of
repos by passing the --read-only flag to hg-ssh.
This is useful in an environment where the number of unix users you
can or are willing to create is limited. In such an environment,
multiple users or applications will share a single unix account. Some
of those applications will likely need read-only access to the
repository. This change makes it possible to grant them such access
without requiring that they use a separate unix account.
I sometimes look at a piece of software and if the man page says
"Copyright 2004", then I'm inclined to think that the project is stale
or that the authors are lazy. Neither is good publicity for us :-)
There is no need to use entropy here just to create some content that only will
be used for hashing and ignored.
This avoids a problem where dd from /dev/urandom on solaris generates too short
output.
This greatly speeds up node->rev lookups, with results that are
often user-perceptible: for instance, "hg --time log" of the node
associated with rev 1000 on a linux-2.6 repo improves from 0.3
seconds to 0.03. I have not found any instances of slowdowns.
The new perfnodelookup command in contrib/perf.py demonstrates the
speedup more dramatically, since it performs no I/O. For a single
lookup, the new code is about 40x faster.
These changes also prepare the ground for the possibility of further
improving the performance of prefix-based node lookups.
