merge with i18n

i18n-ja: synchronized with 61c8327ced50

perf: remove mysterious trailing newlines

blackbox: fix a few check-code portability errors

check-code: fix a check-code failure in check-code The irony is delicious.

check-code: re-add check for missing glob 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.

tests: append missing glob to filename output and check-code it

check-code: extract windows glob warning message it will be used often

blackbox: defer opening a log file until needed (issue3869) Previously, we opened the log file when creating a repo object. This was inefficient (not all repo creation is going to result in a need to log something), but more importantly it broke subrepo updates when used on NFS. * perform an update in the master repo that triggers a subrepo clone * empty subrepo already exists, and has an open, empty blackbox.log file due to it being opened eagerly/prematurely * hg decides to blow away the skeletal subrepo (see use of shutil.rmtree in subrepo._get) * we crash, due to NFS treating a delete of an open file as really a rename to a hidden ".nfs" file Now that we open the blackbox log file on demand, no file exists at the time the empty subrepo is deleted, so the above problem does not occur.

patch: match 'diff --git a/' instead of 'diff --git' This reduces the likelihood of a traceback when trying to email a patch that happens to have 'diff --git' at the beginning of a line in the description, as this patch did: http://markmail.org/message/wxpgowxd7ucxygwe

color: drop unnecessary global statement

serve: pass on the repo instad of recreating it in hgweb When we pass on the path to the repo, the repo is created in hgweb. But the repo is already here, so pass it on.

serve: pass the prepared baseui to hgweb The baseui was carefully prepared but not used. ui can contain repo specific settings which can have unwanted effects.

hgweb: do not pass on repo.ui when recreating a repo Recreate the repo with the global configuration in repo.baseui. The repo configuration is reread anyway. And now deleted repo configuration is reset to the default value.

repo: repo isolation, do not pass on repo.ui for creating new repos A repo should not get the configuration from an other repo, so create it with the global configuration in repo.baseui. This is done too when recreating a repo. The repo configuration is reread anyway. And now deleted repo configuration does not persist.

diff: fix binary file removals in git mode. With the previous version, a binary file removal diff generated with

manifestmerge: drop redundant flags calls

manifestmerge: use dicthelpers.diff and join This patch improves manifestmerge performance significantly. In a repository with 170,000 files, the following results were observed on a clean working directory. Revision '.' adds one file. hg perfmergecalculate -r . - before: 0.41 seconds - after: 0.13 seconds hg perfmergecalculate -r .^ - before: 0.53 seconds - after: 0.24 seconds Comparing against '.' is much faster than comparing against '.^' because with '.', the wctx and p2 manifest strings have the same identity, so comparisons are simply pointer equality. With '.^', the strings have different identities so we need to perform memcmps. Any operation that uses manifestmerge benefits. - hg update . goes from 2.04 seconds to 1.75 - hg update .^ goes from 2.52 seconds to 2.25 - hg rebase -r . -d .~6 (involves 4 merges) goes from 11.8 seconds to 10.8

manifestdict: add a method to diff _flags This will be used in an upcoming patch.

mercurial: implement diff and join for dicts Given two dicts, diff returns a dict containing all the keys that are present in one dict but not the other, or whose values are different between the dicts. The values are pairs of the values from the dicts, with missing values being represented as an optional argument, defaulting to None. Given two dicts, join performs what is known as an outer join in relational database land: it returns a dict containing all the keys across both dicts. The values are pairs as above, except they aren't compared to see if they're the same.

convert: add closesort algorithm to mercurial sources If you actively work with branches, sometimes you need to close old branches which last commited hundreds revisions ago. After close you will see long lines in graph visually spoiling history. This sort only moves closed revisions as close as possible to parents and does not increase storage size as datesort do.

manifestmerge: rename n to n1 and n2 An upcoming patch will combine the two loops into one, so it's important to distinguish between nodes in m1 and nodes in m2.

perf: add a command to measure merge.calculateupdates perf The performance of merge.manifestmerge will be improved in upcoming patches. This command will be used to demonstrate the improvement.

hgk: fix a pyflakes error

dirstate.walk: fast path none-seen + match-always case for step 3 This case is a common one -- e.g. `hg diff`. For a repository with 170,000 files, this speeds up perfstatus from 0.95 seconds to 0.88.

dirstate.walk: fast path match-always case during traversal This case is a common one -- e.g. `hg status`. For a repository with 170,000 files, this speeds up perfstatus --unknown from 2.15 seconds to 2.09.

largefiles: fix _always for match overrides Upcoming patches will speed dirstate.walk up by not filtering based on the match function when match.always() is True. For that to work, match.always() needs to be accurate. Previously it wasn't so for largefiles.

dirstate.walk: remove subrepo and .hg from results before step 3 An upcoming patch will speed dirstate.walk up by not querying the results dict when it is empty. This ensures it is in some common cases. This should be safe because subrepos and .hg aren't part of the dirstate.

merge with stable

blackbox: account for another source of errors

hgk: remove regsub, split on \r instead No need to regsub all \r\n's to \n's, we can just split on \r as well; this may produce extra empty elements in the list, but they won't match anyway.

hgk: simplify tags parser 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.

hgk: add support for phases Add support for phases. Update tests.

hgk: in popups, replace labels with window titles 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.

hgk: update backgroud colour when Ttk is available 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.

hgk: fix pop-up windows Create pop-up windows properly so they go to the floating layer in tiling window managers.

hgk: don't use fixed format for dates Don't pass -format with a date format string, use default instead so users can use their own preferences.

hgk: reformat changsets fields Rename Author to User. Rename Revision to Changeset. Put Date on its own line.

hgk: drop committer field from the UI Remove Committer field, it doesn't make sense in Hg.

test-completion: test completion of tags

debugpathcomplete: satisfy the code checker

tests: test debugpathcomplete and debuglabelcomplete

tests: rename test-debugcomplete.t to test-completion.t

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.

sadclown: another test failure eluded me

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.

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.

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.