i18n-ja: synchronized with ca8ada499529

merge: while checking for unknown files don't follow symlinks (issue5027) Previously, we were using Python's native 'os.path.isfile' method which follows symlinks. In this case, since we're operating on repo contents, we don't want to follow symlinks. There's a behaviour change here, as shown by the second part of the added test. Consider a symlink 'f' pointing to a file containing 'abc'. If we try and replace it with a file with contents 'abc', previously we would have let it though. Now we don't. Although this breaks naive inspection with tools like 'cat' and 'diff', on balance I believe this is the right change.

merge with stable

tests: add test-check-execute.t Try to prevent people from adding files with incorrect execute bits

parents: correct help revset replacements Implementing `hg parents -r REV FILE` correctly is hard. The output can be 0, 1, or 2 revs. First, you can't use parents(), because it sorts its output... Consider: echo $a echo par@rev: `hg log -r "parents($a)" -q` echo p12@rev: `hg log -r "p1($a)+p2($a)" -q` echo parents: `hg parents -q -r $a` (Merge 1 into 0) 3 par@rev: 0:d9612eafe8ec 1:070fe4290d06 p12@rev: 0:d9612eafe8ec 1:070fe4290d06 parents: 0:d9612eafe8ec 1:070fe4290d06 (Merge 4 into 5) 6 par@rev: 4:db73392995c3 5:c26e7dd67644 p12@rev: 5:c26e7dd67644 4:db73392995c3 parents: 5:c26e7dd67644 4:db73392995c3 (Merge 7 into 8) 9 par@rev: 7:d84f47462f70 8:9597bcab36e0 p12@rev: 8:9597bcab36e0 7:d84f47462f70 parents: 8:9597bcab36e0 7:d84f47462f70 You also can't use parents or/p1/p2 alone with a set, as in: -r "parents(::REV and file(FILE))" -r "parents(::REV - REV and file(FILE))" ... because each will return all parents for each candidate revision, and the :: gives too many candidates. Thus, we need a max and a p1/p2. Also, anything of this form: max(::REV - REV and file(FILE)) ... is wrong, because max will return only one revision, and for a proper parents, you need to return two occasionally. Lastly, it doesn't help that `hg parents -r REV FILE` is buggy due to a quirk in filelogs. Here's a repository to consider when evaluating whether your revset is correct: $ hg log -G --template '{rev} {files}\n'; @ 10 a | o 9 a b |\ | o 8 a | | o | 7 a | | +---o 6 b | |/ | o 5 b | | o | 4 b | | +---o 3 | |/ +---o 2 | |/ | o 1 b | o 0 a revs 4 and 5 create a conflict. The conflict is resolved in the same way by both 6 and 9. You would hope that parents around 9/10 would point to 9, but `hg parents` will point to 6 due to the aforementioned bug. Here's the winning solution test script and its output. echo $a; echo rp12-max: `hg log -r "max(::p1($a) and file(b)) + max(::p2($a) and file(b))" -q` 2> /dev/null; echo expected: `hg parents -q -r $a b` 2> /dev/null; Note that for 10, the output differs, but again, this is because of the aforementioned bug. The rp12-max output is "correct", whereas "expected" is just an unfortunate bug. The abort output is due to something else. I'm not sure why someone thought it was important to abort to stdio instead of stderr, but that's really not my problem here. 10 rp12-max: 9:184ebefc2fce expected: 6:dd558142b03f 9 rp12-max: 5:c26e7dd67644 4:db73392995c3 expected: 5:c26e7dd67644 4:db73392995c3 8 rp12-max: 5:c26e7dd67644 expected: 5:c26e7dd67644 7 rp12-max: 4:db73392995c3 expected: 4:db73392995c3 6 rp12-max: 5:c26e7dd67644 4:db73392995c3 expected: 5:c26e7dd67644 4:db73392995c3 5 rp12-max: 1:070fe4290d06 expected: 1:070fe4290d06 4 rp12-max: abort: 'b' not found in manifest! expected: 3 rp12-max: 1:070fe4290d06 expected: 1:070fe4290d06 2 rp12-max: 1:070fe4290d06 expected: 1:070fe4290d06 1 rp12-max: abort: 'b' not found in manifest! expected: 0 rp12-max: abort: 'b' not found in manifest! expected:

run-tests: avoid double counting server fails

commandserver: reset state of progress bar per command A progress bar is normally disabled in command-server session, but chg can enable it. This patch makes sure the last-print time is measured per command. Otherwise, progress.delay could be ineffective if a progbar was loaded before forking worker process. This patch is corresponding to the following change. https://bitbucket.org/yuja/chg/commits/2dfe3e90b365

commandserver: do not set nontty flag if channel is replaced by a real file This prepares for porting the chg server. In chg, a server receives client's stdio over a UNIX domain socket to override server channels. This is because chg should behave as if it is a normal hg command attached to tty. "nontty" is not wanted. This patch is corresponding to the following change. This doesn't test the identity of "cin" object because the current version of chg reopens stdio to apply buffering mode. https://bitbucket.org/yuja/chg/commits/c48c7aed5fc0

run-tests: report missing feature for skipped tests

paths: do not process default-push as pushurl of default path (issue5000) It didn't work because "default-push" and "default" are independent named items. Without this patch, "hg push default" would push to "default-push" because paths["default"].pushloc was overwritten by "default-push". Also, we shouldn't ban a user from doing "hg push default-push" so long as "default-push" item is defined, not "default:pushurl". Otherwise, he would be confused by missing "default-push" path. Tests are included in a patch for stable branch.

push: specify default-push and default as fallback paths The next patch will remove the "default-push" hack from ui.paths so that ui.paths["default"].pushurl can be different from "default-push".

paths: make getpath() accept multiple defaults This is necessary to handle "default-push" and "default" as fallback items. We can't apply the same rule as "default:pushurl" because "default-push" is a valid named path. This series is for default branch. I have a simpler patch for stable.

check-code: improve test-check-code error diffs Whenever check-code finds something wrong, the diffs it generated were fairly hard to read. The problem is that check-code before this change would list files that were white listed using no- check- code but without a glob marker. Whereas, the test-check-code.t expected output has no-che?k-code (glob) in order to avoid having itself flagged as a file to skip. Thus, in addition to any lines relating to things you did wrong, all of the white-listed files are listed as changed. There is no reason for things to be this painful. This change makes the output from check-code.py match the expected output in test-check-code.t

destutil: use scmutil.revrange for desthistedit (issue5001) This allows user aliases to be expanded. It also prevents the user-provided revset from being treated as a revset expression.

pull: make a single call to obsstore.add (issue5006) Prior to this, a pull of 90k markers (already known locally!) was making about 2000 calls to obsstore.add, which was repeatedly building a full set of known markers (in addition to other transaction overhead). This quadratic behavior accounted for about 50 seconds of a 70 second no-op pull. After this change, we're down to 20 seconds. While it would seem simplest to just cache the known set for obsstore.add, this would also introduce issues of correct cache invalidation. The extra pointless transaction overhead would also remain.

tests: Solaris diff -U also emits "No differences encountered" This came up before, but the tests in check-code.py don't find -U (only -u) and they don't work when the diff is inside a shell function. This fixes the offending tests and beefs up check-code.py.

test-glog: avoid check-code violation after next patch Danek's patch will help us avoid spurious test breakages on Solaris. This test wasn't broken on Solaris because of the grep(1) use, but it will upset check-code. Use cmp to silence check-code since it doesn't matter.

push: restore old behavior of default-push (issue5000) This effectively backs out dceaef70e410 and 10917b062adf. We can't handle "default-push" just like "default:pushurl" because it is a stand-alone named path. Instead, I have two ideas to work around the issue: a. two defaults: getpath(dest, default=('default-push', 'default')) b. virtual path: getpath(dest, default=':default') (a) is conservative approach and will have less trouble, but callers have to specify they need "default-push" or "default". (b) generates hidden ":default" path from "default" and "default-push", and callers request ":default". This will require some tricks and won't work if there are conflicting sub-options valid for both "pull" and "push". I'll take (a) for default branch. This patch should NOT BE MERGED to default except for tests because it would break handling of "pushurl" sub-option.

hgweb: fixed invalid atom-log feed url in file log page currently "subscribe to atom feed" link in file log page is as follows. /atom-log/[revision]/[file] This is invalid, because we could not get newer commit feed than [revision]. To fix this, atom-log feed url should be the following style. atom-log/tip/[file]

repair: improves documentation of strip regarding locks This patch adds a comment making it clear that we should hold a lock before calling repair.strip. The wording is the same than what we have for obsolete.createmarkers

help: remove stray double spaces from config help

help: clarify that the config hook priority prefix includes a period

monoblue: correct feed links on /branches, /tags and /bookmarks

gitweb: describe feed type in links on /branches, /tags and /bookmarks

gitweb: link to the correct feeds from help pages

histedit: handle exceptions from node.bin in fromrule

histedit: limit cleanup of histedit-last-edit.txt to success

histedit: use parse-error exception for parsing

test-histedit-edit: test histedit with dirty repo

histedit: limit mentioning histedit-last-edit.txt Before histedit-last-edit.txt would be mentioned for any failure. After, it should only be mentioned for failures relating to user input.