- Mar 21, 2013
-
-
Bryan O'Sullivan authored
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.
-
Bryan O'Sullivan authored
The bash_completion code uses "hg status" to generate a list of possible completions for commands that operate on files in the working directory. In a large working directory, this can result in a single tab-completion being very slow (several seconds) as a result of checking the status of every file, even when there is no need to check status or no possible matches. The new debugpathcomplete command gains performance in a few simple ways: * Allow completion to operate on just a single directory. When used to complete the right commands, this considerably reduces the number of completions returned, at no loss in functionality. * Never check the status of files. For completions that really must know if a file is modified, it is faster to use status: hg status -nm 'glob:myprefix**' Performance: Here are the commands used by bash_completion to complete, run in the root of the mozilla-central working dir (~77,000 files) and another repo (~165,000 files): All "normal state" files (used by e.g. remove, revert): mozilla other status -nmcd 'glob:**' 1.77 4.10 sec debugpathcomplete -f -n 0.53 1.26 debugpathcomplete -n 0.17 0.41 ("-f" means "complete full paths", rather than the current directory) Tracked files matching "a": mozilla other status -nmcd 'glob:a**' 0.26 0.47 debugpathcomplete -f -n a 0.10 0.24 debugpathcomplete -n a 0.10 0.22 We should be able to further improve completion performance once the critbit work lands. Right now, our performance is limited by the need to iterate over all keys in the dirstate.
-
Bryan O'Sullivan authored
-
Bryan O'Sullivan authored
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.
-
Bryan O'Sullivan authored
-
Simon Heimberg authored
os.listdir returns the files in any order. This has to be sorted. But when given as argument, the user should be allowed to set any order. This restores the behaviour before 9848a94e2ad6.
-
- Mar 20, 2013
-
-
Bryan O'Sullivan authored
On Windows, our implementation is more robust than Python's version.
-
Bryan O'Sullivan authored
Instead, we simply print a warning message if opening the blackbox log file fails, or if writing to it fails.
-
- Mar 19, 2013
-
-
Bryan O'Sullivan authored
-
Siddharth Agarwal authored
lfutil.splitstandin(f) can be None, and we query the dirstate for that without checking if it is. This will cause problems with the upcoming move to critbit- based dicts, since they only support strings as keys.
-
Kevin Bullock authored
-
- Mar 17, 2013
-
-
Kevin Bullock authored
After this change, moving the active bookmark somewhere other than the current changeset (i.e., with --rev) deactivates it. Previously it would remain in .hg/bookmarks.current, which seems like a bug.
-
Kevin Bullock authored
Allow a bookmark that points to the current changeset to be made the active bookmark without requiring --force. Previously, this would've aborted with: abort: bookmark 'Z' already exists (use -f to force)
-
- Mar 18, 2013
-
-
Kevin Bullock authored
The variable 'fd' was getting used with a value left over from a prior iteration, causing a KeyError: '.hgsubstate'.
-
Kevin Bullock authored
This makes the tag("re:...") revset consistent with branch("re:...").
-
- Mar 15, 2013
-
-
Durham Goode authored
When a series of commits first adds a file and then removes it, hg rebase --collapse prompts whether to keep the file or delete it. This is due to it reusing the branch merge code. In a noninteractive terminal it defaults to keeping the file, which results in a collapsed commit that is has a file that should be deleted. This bug resulted in developers accidentally commiting unintentional changes to our repo twice today, so it's fairly important to get fixed. This change allows rebase --collapse to tell the merge code to accept the latest version every time without prompting. Adds a test as well.
-
- Mar 18, 2013
-
-
durin42 authored
-
- Mar 11, 2013
-
-
Bryan O'Sullivan authored
Since re2 is enormously faster than Python's re module, this should help performance, ceteris paribus. grep currently has other huge performance problems that mask any gain :-(
-
Bryan O'Sullivan authored
-
- Mar 17, 2013
-
-
Kevin Bullock authored
The added test reflects an error in printing the origin node of the bookmark that I fixed before committing, but I forgot to update the test (whoops).
-
- Mar 16, 2013
-
-
Kevin Bullock authored
Allow 'hg bookmark MARK', with an existing bookmark MARK, to move the bookmark forward to the current or specified revision, if the target revision is a descendant of the revision the bookmark currently points to. Prints a status message including the revision the bookmark was formerly at: $ hg bookmark Z moving bookmark 'Z' forward from 663762316562 Test coverage is added.
-
- Feb 26, 2013
-
-
Angel Ezquerra authored
When the web server shows the manifest for a single, non top directory, append the path to the directory to the archive links. This makes the web server generate archive files that only include the current directory (and its subdirectories). Note that archive links in other pages (e.g. changeset) or at the top of the manifest are unchanged. Directory archive links have an extra "/" at the end which does not impact the result of the archive operation. Keeping it there made the implementation of this feature simpler.
-
- Feb 10, 2013
-
-
Angel Ezquerra authored
The archive web command now takes into account the "file" request entry, if one is provided. The provided "file" is processed as a "path" corresponding to a directory or file that will be downloaded. With this change hgweb can to process requests such as: http://mercurial.selenic.com/hg/archive/tip.zip/mercurial/templates This will download all files on the mercurial/templates directory as a zip file. It is not possible to specify file patterns ('glob', 'relglob', 'path', 'relpath', 're', 'relre' nor 'set'). The server will reject those with a 403 HTTP error response. Note that this is a first step to add support for downloading directories from the web interface. A following patch will modify the archiveentry map entry on the different templates so that it adds the current folder path to the archive links.
-
- Feb 06, 2013
-
-
Angel Ezquerra authored
This avoids pritting out a traceback when a get-with-headers call causes hgweb to respond with an HTTPError code.
-
- Mar 14, 2013
-
-
Bryan O'Sullivan authored
-
Bryan O'Sullivan authored
Previously, we only completed files that had already been manually deleted. That behaviour made no sense. We now complete unmodified, modified, and deleted files.
-
Bryan O'Sullivan authored
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).
-
- Mar 13, 2013
-
-
Durham Goode authored
Writes the backup bundle paths to the blackbox so it's easy to see which backup bundle is associated with which command when you are debugging an issue. Example output: 2013/03/13 10:39:56 durham> strip tip 2013/03/13 10:39:59 durham> saved backup bundle to /data/users/durham/www-hg/.hg/strip-backup/e5fac262363a-backup.hg 2013/03/13 10:40:03 durham> strip tip exited 0 after 7.97 seconds
-
- Mar 12, 2013
-
-
Durham Goode authored
The test-profile test would fail if the user had HGPROF set to another profiler in their environment. This fix makes the test independent of that environment variable. Reverts the previous attempt to fix this, which was not cross platoform.
-
Bryan O'Sullivan authored
-
Durham Goode authored
The test-profile test would fail if the user had HGPROF set to another profiler in their environment. This fix makes the test independent of that environment variable.
-
- Mar 09, 2013
-
-
Simon Heimberg authored
The prefix has not been removed when this check changed from a warning to a failure.
-
- Mar 10, 2013
-
-
Bryan O'Sullivan authored
-
- Mar 07, 2013
-
-
Durham Goode authored
hg strip -k was using dirstate.rebuild() which reset all the dirstate entries timestamps to 0. This meant that the next time hg status was run every file was considered to be 'unsure', which caused it to do expensive read operations on every filelog. On a repo with >150,000 files it took 70 seconds when everything was in memory. From a cold cache it took several minutes. The fix is to only reset files that have changed between the working context and the destination context. For reference, --keep means the working directory is left alone during the strip. We have users wanting to use this operation to store their work-in-progress as a commit on a branch while they go work on another branch, then come back later and be able to uncommit that work and continue working. They currently use 'git reset HARD^' to accomplish this in git.
-
- Mar 09, 2013
-
-
Durham Goode authored
When running 'hg pull --rebase', I was seeing this exception 100% of the time as the python process was closing down: Exception TypeError: TypeError("'NoneType' object is not callable",) in <bound method Popen.__del__ of <subprocess.Popen object at 0x937c10>> ignored By storing the subprocess on the sshpeer, the subprocess seems to clean up correctly, and I no longer see the exception. I have no idea why this actually works, but I get a 0% repro if I store the subprocess in self.subprocess, and a 100% repro if I store None in self.subprocess. Possibly related to issue 2240.
-
- Feb 28, 2013
-
-
Durham Goode authored
When running commands like 'hg export -o mypatch-%N.patch', the blackbox would throw an exception because it tried to format %N. This change prevents it from trying to format the command string.
-
- Mar 19, 2013
-
-
Bryan O'Sullivan authored
-
- Mar 11, 2013
-
-
Durham Goode authored
When a rebase has conflicts and the user uses rebase --continue, the previously active bookmark was not being made active once again. With this change that bookmark is made active again, just as if the rebase had never been interrupted. This changes the rebasestate file format, but should handle old formats correctly. Since the file is transient, this is even less of a problem. Adds a test to verify the new behavior. I manually tested continuing rebases with and without an active bookmark, and with and without being on the bookmark being rebased.
-
- Mar 04, 2013
-
-
Benoit Boissinot authored
Fix version detection with recent hg versions.
-
Benoit Boissinot authored
This allows updating PyPI with just 'setup.py register' (assuming the user is an owner or maintainer of the PyPI package).
-