Tue, 16 Oct 2012 15:07:41 +0200 hgk: drop committer field from the UI
Andrew Shadura <bugzilla@tut.by> [Tue, 16 Oct 2012 15:07:41 +0200] rev 18801
hgk: drop committer field from the UI Remove Committer field, it doesn't make sense in Hg.
Thu, 21 Mar 2013 22:42:51 -0700 test-completion: test completion of tags
Bryan O'Sullivan <bryano@fb.com> [Thu, 21 Mar 2013 22:42:51 -0700] rev 18800
test-completion: test completion of tags
Thu, 21 Mar 2013 22:29:31 -0700 debugpathcomplete: satisfy the code checker
Bryan O'Sullivan <bryano@fb.com> [Thu, 21 Mar 2013 22:29:31 -0700] rev 18799
debugpathcomplete: satisfy the code checker
Thu, 21 Mar 2013 22:26:01 -0700 tests: test debugpathcomplete and debuglabelcomplete
Bryan O'Sullivan <bryano@fb.com> [Thu, 21 Mar 2013 22:26:01 -0700] rev 18798
tests: test debugpathcomplete and debuglabelcomplete
Thu, 21 Mar 2013 22:22:21 -0700 tests: rename test-debugcomplete.t to test-completion.t
Bryan O'Sullivan <bryano@fb.com> [Thu, 21 Mar 2013 22:22:21 -0700] rev 18797
tests: rename test-debugcomplete.t to test-completion.t
Thu, 21 Mar 2013 22:10:54 -0700 pathcomplete: complete directories more conservatively
Bryan O'Sullivan <bryano@fb.com> [Thu, 21 Mar 2013 22:10:54 -0700] rev 18796
pathcomplete: complete directories more conservatively Suppose we want to perform a single-level completion (i.e. without --full) of "fi" in a repo containing "fee", "fie/dead", "fie/live", and "foe". If we give back "fie/" as the only answer, the shell will consider the completion to be unambiguous, and will append a space after the completion. We can't complete "fie/live" or "fie/dead" without first backspacing over that space. We used to thus create two fake names, "fie/a" and "fie/b", to force the shell to consider the completion to be ambiguous. It would then stop at "fie/" without appending a space, allowing us to hit tab again to complete "fie/live" or "fie/dead". The change here arises from realising that we only need to force the shell to consider a completion as ambiguous if we have exactly one directory and zero files as possible completions. This prevents spurious names from showing up as possible completions when they don't need to be invented in the first place.
Thu, 21 Mar 2013 21:20:40 -0700 sadclown: another test failure eluded me
Bryan O'Sullivan <bryano@fb.com> [Thu, 21 Mar 2013 21:20:40 -0700] rev 18795
sadclown: another test failure eluded me
Thu, 21 Mar 2013 21:07:22 -0700 bash_completion: recognize normal command abbreviations
Bryan O'Sullivan <bryano@fb.com> [Thu, 21 Mar 2013 21:07:22 -0700] rev 18794
bash_completion: recognize normal command abbreviations In many common cases, this eliminates a call to "hg help" to get a complete command name, thus improving responsiveness.
Thu, 21 Mar 2013 16:31:29 -0700 completion: selectively use debugpathcomplete in bash_completion
Bryan O'Sullivan <bryano@fb.com> [Thu, 21 Mar 2013 16:31:29 -0700] rev 18793
completion: selectively use debugpathcomplete in bash_completion 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.
Thu, 21 Mar 2013 16:31:28 -0700 completion: add a debugpathcomplete command
Bryan O'Sullivan <bryano@fb.com> [Thu, 21 Mar 2013 16:31:28 -0700] rev 18792
completion: add a debugpathcomplete command 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.
Thu, 21 Mar 2013 11:35:34 -0700 tests: add new command to test-debugcomplete
Bryan O'Sullivan <bryano@fb.com> [Thu, 21 Mar 2013 11:35:34 -0700] rev 18791
tests: add new command to test-debugcomplete
Thu, 21 Mar 2013 10:51:18 -0700 completion: add a debuglabelcomplete command
Bryan O'Sullivan <bryano@fb.com> [Thu, 21 Mar 2013 10:51:18 -0700] rev 18790
completion: add a debuglabelcomplete command 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.
Thu, 21 Mar 2013 09:13:16 -0700 bash_completion: nuke a duplicated function
Bryan O'Sullivan <bryano@fb.com> [Thu, 21 Mar 2013 09:13:16 -0700] rev 18789
bash_completion: nuke a duplicated function
Thu, 21 Mar 2013 08:56:21 +0100 run-tests: only sort files when not given as argument
Simon Heimberg <simohe@besonet.ch> [Thu, 21 Mar 2013 08:56:21 +0100] rev 18788
run-tests: only sort files when not given as argument 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 9848a94e2a.
Wed, 20 Mar 2013 13:40:06 -0700 blackbox: use util.getuser for portability
Bryan O'Sullivan <bryano@fb.com> [Wed, 20 Mar 2013 13:40:06 -0700] rev 18787
blackbox: use util.getuser for portability On Windows, our implementation is more robust than Python's version.
Wed, 20 Mar 2013 13:40:05 -0700 blackbox: prevent failed I/O from causing hg to abort
Bryan O'Sullivan <bryano@fb.com> [Wed, 20 Mar 2013 13:40:05 -0700] rev 18786
blackbox: prevent failed I/O from causing hg to abort Instead, we simply print a warning message if opening the blackbox log file fails, or if writing to it fails.
Tue, 19 Mar 2013 16:19:45 -0700 merge with crew-stable
Bryan O'Sullivan <bryano@fb.com> [Tue, 19 Mar 2013 16:19:45 -0700] rev 18785
merge with crew-stable
Tue, 19 Mar 2013 13:49:34 -0700 largefiles: don't query the dirstate for key None
Siddharth Agarwal <sid0@fb.com> [Tue, 19 Mar 2013 13:49:34 -0700] rev 18784
largefiles: don't query the dirstate for key None 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.
Mon, 18 Mar 2013 19:59:05 -0500 merge
Kevin Bullock <kbullock@ringworld.org> [Mon, 18 Mar 2013 19:59:05 -0500] rev 18783
merge
Sat, 16 Mar 2013 22:48:22 -0500 bookmarks: moving the active bookmark deactivates it
Kevin Bullock <kbullock@ringworld.org> [Sat, 16 Mar 2013 22:48:22 -0500] rev 18782
bookmarks: moving the active bookmark deactivates it 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.
Sat, 16 Mar 2013 21:36:44 -0500 bookmarks: allow (re-)activating a bookmark on the current changeset
Kevin Bullock <kbullock@ringworld.org> [Sat, 16 Mar 2013 21:36:44 -0500] rev 18781
bookmarks: allow (re-)activating a bookmark on the current changeset 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)
Mon, 18 Mar 2013 16:37:20 -0500 applyupdates: assign variable before we try to use it (issue3855)
Kevin Bullock <kbullock@ringworld.org> [Mon, 18 Mar 2013 16:37:20 -0500] rev 18780
applyupdates: assign variable before we try to use it (issue3855) The variable 'fd' was getting used with a value left over from a prior iteration, causing a KeyError: '.hgsubstate'.
Mon, 18 Mar 2013 16:04:10 -0500 revset: don't abort when regex to tag() matches nothing (issue3850)
Kevin Bullock <kbullock@ringworld.org> [Mon, 18 Mar 2013 16:04:10 -0500] rev 18779
revset: don't abort when regex to tag() matches nothing (issue3850) This makes the tag("re:...") revset consistent with branch("re:...").
Fri, 15 Mar 2013 11:23:29 -0700 rebase: fix --collapse when a file was added then removed
Durham Goode <durham@fb.com> [Fri, 15 Mar 2013 11:23:29 -0700] rev 18778
rebase: fix --collapse when a file was added then removed 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.
Sun, 17 Mar 2013 23:27:14 -0500 Merge
Augie Fackler <raf@durin42.com> [Sun, 17 Mar 2013 23:27:14 -0500] rev 18777
Merge
Mon, 11 Mar 2013 12:07:33 -0700 grep: use re2 if possible
Bryan O'Sullivan <bryano@fb.com> [Mon, 11 Mar 2013 12:07:33 -0700] rev 18776
grep: use re2 if possible 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 :-(
Mon, 11 Mar 2013 12:06:13 -0700 util: add flag support to compilere
Bryan O'Sullivan <bryano@fb.com> [Mon, 11 Mar 2013 12:06:13 -0700] rev 18775
util: add flag support to compilere
Sat, 16 Mar 2013 21:21:54 -0500 bookmarks: fix test broken by 0bba1ff2ac7b
Kevin Bullock <kbullock@ringworld.org> [Sat, 16 Mar 2013 21:21:54 -0500] rev 18774
bookmarks: fix test broken by 0bba1ff2ac7b 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).
Fri, 15 Mar 2013 23:39:07 -0500 bookmarks: allow moving a bookmark forward to a descendant
Kevin Bullock <kbullock@ringworld.org> [Fri, 15 Mar 2013 23:39:07 -0500] rev 18773
bookmarks: allow moving a bookmark forward to a descendant 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.
Tue, 26 Feb 2013 21:20:35 +0100 hgweb: change manifest archive links to only archive the current directory
Angel Ezquerra <angel.ezquerra@gmail.com> [Tue, 26 Feb 2013 21:20:35 +0100] rev 18772
hgweb: change manifest archive links to only archive the current directory 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.
(0) -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 +30000 tip