merge: add options to warn or ignore on colliding unknown files A 'colliding unknown file' is a file that meets all of the following conditions: - is untracked or ignored on disk - is present in the changeset being merged or updated to - has different contents Previously, we would always abort whenever we saw such files. With this config option we can choose to warn and back the unknown files up instead, or even forgo the warning entirely and silently back the unknown files up. Common use cases for this configuration include a large scale transition of formerly ignored unknown files to tracked files. In some cases the files can be given new names, but in other cases, external "convention over configuration" constraints have determined that the file must retain the same name as before.

batchget: add support for backing up files We're going to use this in an upcoming feature.

merge: add a new 'backup' argument to get actions We're going to use this in an upcoming patch to back untracked files up when they're replaced by tracked ones.

_checkunknownfiles: turn 'conflicts' into a set We'll check for membership in this set in an upcoming patch.

checkunknownfiles: make control flow clearer In particular, make it clear that we only check for and abort on conflicts if force is not true.

_checkunknownfiles: rename 'aborts' to 'conflicts' In upcoming patches we'll be able to do more useful things than aborting.

origpath: move from cmdutil to scmutil This is a lower-level function so it doesn't need to be in cmdutil, and putting it here avoids a bunch of potential import cycle issues.

revlog: remove unnecessary cache validation in _chunks Previously, we likely called _chunkraw() multiple times in order to ensure it didn't change out from under us. I'm pretty certain this code had its origins in the days where we attempted to have thread safety of localrepository and thus revlog instances. revlog instances are already not thread safe for writing. And, as of Mercurial 3.6, hgweb uses a separate localrepository instance per request, so there should only be a single thread reading a revlog at a time. We more or less decided that attempting to make classes like revlog thread safe is a lost cause. So, this patch removes thread safety from _chunks. As a result, we make one less call into _chunkraw() when the initial read isn't serviced by the cache. This translates to savings of 4 function calls overall and possibly prevents the creation of an additional buffer view into the cache. I doubt this translates into any real world performance wins because decompression will almost certainly dwarf time spent in _chunks(). But it does make the code simpler, so it is an improvement.

revlog: return offset from _chunkraw() A subsequent patch will refactor _chunks() and the calculation of the offset will no longer occur in that function. Prepare by returning the offset from _chunkraw().

verify: get rid of some unnecessary local variables Now that all the major functionality has been refactored out, we can delete some unused local variables.

verify: move changelog verificaiton to its own function This makes verify more modular so extensions can hook into it.

verify: move manifest verification to its own function This makes verify more modular, making it easier for extensions to extend.

verify: move file cross checking to its own function This is part of making verify more modular so extensions can hook into it.

verify: move filelog verification to its own function This makes verify more modular so extensions can hook in more easily.

verify: move checkentry() to be a class function This is part of making verify more modular so extensions can hook into it.

verify: move checklog() onto class This is part of an effort to make verify more modular so extensions can hook into it.

dockerrpm: fix CentOS 5 RPMs (issue4977) The older rpmbuild in CentOS 5 fails if some of the output directories have not been created yet. This change results in creating those directories.

check-code: enforce strict spacing around assignment

cleanup: remove superfluous space after space after equals (tests)

cleanup: remove superfluous space after space after equals (C)

cleanup: remove superfluous space after space after equals (python)

tests: make a stab at approximating wall-clock times Vaguely empirical observations: * ".py" tests are about an order of magnitude faster than ".t" tests * dividing size by 1000 gives an approximation to wall-clock run time (in seconds) that is not completely ridiculous.

tests: only stat a test file if we don't already know its "cost"

tests: write recent run times to a file named tests/.testtimes This is an effortless way to track how long each test takes without having to pass any extra command line options.

wireproto: support disabling bundle1 only if repo is generaldelta I recently implemented the server.bundle1* options to control whether bundle1 exchange is allowed. After thinking about Mozilla's strategy for handling generaldelta rollout a bit more, I think server operators need an additional lever: disable bundle1 if and only if the repo is generaldelta. bundle1 exchange for non-generaldelta repos will not have the potential for CPU explosion that generaldelta repos do. Therefore, it makes sense for server operators to continue to allow bundle1 exchange for non-generaldelta repos without having to set a per-repo hgrc option to change the policy depending on whether the repo is generaldelta. This patch introduces a new set of options to control bundle1 behavior for generaldelta repos. These options enable server operators to limit bundle1 restrictions to the class of repos that can be performance issues. It also allows server operators to tie bundle1 access to store format. In many server environments (including Mozilla's), legacy repos will not be generaldelta and new repos will or might be. New repos often aren't bound by legacy access requirements, so setting a global policy that disallows access to new/generaldelta repos via bundle1 could be a reasonable policy in many server environments. This patch makes this policy very easy to implement (modify global hgrc, add options to existing generaldelta repos to grandfather them in).

streamclone: use read() We have a convenience API for reading the full contents of a file. Use it.

internals: document revlog format It seems like a good idea to document the revlog format. There is a lot more that could be added to this documentation. But you have to start somewhere.

histedit: hide --outgoing warnings

histedit: list action when intervention is required

error: make InterventionRequired take a hint

histedit: hook afterresolvedstates

rebase: hook afterresolvedstates

graft: hook afterresolvedstates

resolve: suggest the next action Expose afterresolvedstates to allow graft and similar to suggest a message when resolving results in no unresolved files. If there isn't a matching state in afterresolvedstates, then if verbose, suggest commiting.

dispatch: report similar names consistently

cmdutil: pass node instead of ctx to diffordiffstat 93bcc73df8d5 changed showpatch to use ctx's more, but it accidentally passed prev as a context and node as a binary string, when both should be passed as binary strings (since diffordiffstat tries to resolve them via repo[X]). This affected hggit since the existing ctx belongs to the git overlay, but the resolved context (from the repo[X] resolution) should belong to the main repo. This broke a test because it tried to look in the git repo for data that didn't exist. This feels like a deeper issue in hggit somewhere, but the fix is here trivial and obviously more correct

import-checker: list package directory as stdlib module Before this patch, a directory containing __init__.py wasn't counted as a module and __init__.pyc was listed as foo.bar.__init__ module.

import-checker: normalize directory separator to get module name on Windows It didn't work if a path contains "\\". Therefore, ctypes.util couldn't be found on Windows.

mail: use print function We no longer use the print statement in mercurial.* \o/

lsprofcalltree: use print function While I was here, some single element tuples have been removed in favor of the shorter syntax. Some commented lines of code containing print statements have also been removed because it was unclear what purpose they served.

lsprof: use print function

keepalive: use print function

dispatch: use print function Python 3 doesn't have a print statement.

help: include section heading if section depth changes This makes it easier to distinguish between: "format" -------- "usestore" ... Enabled by default. and "progress.format" Format of the progress bar.

import: refactor nocommit and importbranch handling

import: refactor date and user handling

import: limit scope of msg in tryimportone

merge with stable

lazymanifest: check error return in filter

lazymanifest: add missing closing parenthesis in comment

help: rename the Format section to Structure This reduces the confusion from `hg help config.format` which deals with repository format. (But also profiling.format, and progress.format)

help: refactor version/defaults from format section The old messages implied that disabling a single setting would ensure compatibility, but if you disabled one of the older flags, and left a newer flag, that would not actually do what the docs say.

help: sort format section from newest to oldest

histedit: fix comment in newnodestoabort

histedit: fix comment in applychanges

run-tests: fix get port to try differing ports The code was moving its offset each time through the loop, but because it failed to update port, the port was not going to be available...

httpclient: update to 938f2107d6e2 of httpplus This enhances proxy support in httpclient a little bit, though I don't know that we used that functionality at all. It also switches httpplus to using absolute_import.

histedit: remove unused variable state

filemerge: default change/delete conflicts to 'leave unresolved' (BC) It makes far more sense to leave these conflicts unresolved and kick back to the user than to just assume that the local version be chosen. There are almost certainly buggy scripts and applications using Mercurial in the wild that do merges or rebases non-interactively, and then assume that if the operation succeeded there's nothing the user needs to pay attention to. (This wasn't possible earlier because there was no way to re-resolve change/delete conflicts -- but now it is.)

tests: explicitly request changed version in test-rebase-newancestor.t We're going to change the default for this in an upcoming patch, but in this instance we do want to continue picking the changed version.

tests: explicitly request changed version in c/d conflict in test-commit-amend.t We're going to change the default for this in an upcoming patch, but in this instance we do want to continue picking the changed version.

test-copy-move-merge.t: explicitly request changed version We're going to change the default for this in an upcoming patch, but in this instance we do want to continue picking the changed version.

match: add option to return line and lineno from readpattern This will be used to display the line and linenumber of ignorefile that matched an ignored file (issue4856).

dirstate: extract logic to compute the list of ignorefiles We are going to reuse this logic to improve debugignore in the next patches of the series.

dirstate: call the C implementation of nonnonormalentries when available Before this patch, we were using python code for computing the nonnormal dirstate entries. This patch makes us use the C implementation of the function when it is available. Using the nonnormal set in hgwatchman improves hg status performance. Below are the numbers for mozilla-central. with the changes: $ hg perfstatus ! wall 0.010632 comb 0.000000 user 0.000000 sys 0.000000 (best of 246) without the changes: $ hg perfstatus ! wall 0.036442 comb 0.030000 user 0.030000 sys 0.000000 (best of 100) On mozilla-central the improvement to hg status is ~20% (0.25s to 0.2s), on our big repos at Facebook, the win is ~40% (1.2s to 0.72s).

dirstate: add a C implementation for nonnormalentries Before this patch, there was only a python version of nonnormalentries. On mozilla-central we have a 10x win by putting this function in C: % python -m timeit -s \ 'from mercurial import hg, ui, parsers; \ repo = hg.repository(ui.ui(), "mozilla-central"); \ m = repo.dirstate._map' \ 'parsers.nonnormalentries(m)' 100 loops, best of 3: 3.15 msec per loop The python implementation runs in 31ms, a similar test gives: 10 loops, best of 3: 31.7 msec per loop On our big repos, the win is still of 10x with the python implementation running in 350ms and the C implementation running in 30ms.

dirstate: add test for non-normal set consistency This adds a test extension to check that the non-normal set contains the expected entries. It wraps several methods of the dirstate to check that the non-normal set has the correct values before and after the call. The extension lives in contrib so that paranoid developers can easily enable it to make sure that the non-normal set is consistent across more complex operations than the included tests.

dirstate: add code to update the non-normal set Before this patch, we were only populating the non-normal set when parsing or packing the dirstate. This was not enough to keep the non-normal set up to date at all time as we don't write and read the dirstate whenever a change happens. This patch solves this issue by updating the non-normal set when it should be updated. note: pack_dirstate changes the dmap and we have it keep it unchanged for retrocompatibility so we are forced to recompute the non-normal set after calling it.

dirstate: attach the nonnormalset to a propertycache This patch attaches the nonnormalset to a property cache so that we build it only when needed.

dirstate: add a function to compute non-normal entries from the dmap This patch adds a new python function in the dirstate to compute the set of non-normal files from the dmap. These files are useful to compute the repository status.

revset: use decorator to mark a predicate as safe Using decorator can localize changes for adding (or removing) a "safe" revset predicate function in source code. To avoid accidentaly treating unsuitable predicates as safe, this patch uses False as default value of "safe" argument. This forces safe predicates to be decorated with explicit 'safe=True'.

revset: use delayregistrar to register predicate in extension easily Previous patch introduced 'revset.predicate' decorator to register revset predicate function easily. But it shouldn't be used in extension directly, because it registers specified function immediately. Registration itself can't be restored, even if extension loading fails after that. Therefore, registration should be delayed until 'uisetup()' or so. This patch uses 'extpredicate' decorator derived from 'delayregistrar' to register predicate in extension easily. This patch also tests whether 'registrar.delayregistrar' avoids function registration if 'setup()' isn't invoked on it, because 'extpredicate' is the first user of it.

registrar: add delayregistrar class to register function in extensions 'delayregistrar' delays actual registration of function until 'setup()' invocation on it.

revset: use decorator to register a function as revset predicate Using decorator can localize changes for adding (or removing) a revset predicate function in source code. It is also useful to pick predicates up for specific purpose. For example, subsequent patch marks predicates as "safe" by decorator. This patch defines 'parsefuncdecl()' in 'funcregistrar' class, because this implementation can be uesd by other decorator class for fileset predicate and template function.

registrar: add funcregistrar class to register function for specific purpose This class centralizes the common logic to register function for specific purpose like below: - template keyword, filter and function - revset predicate - fileset predicate - webcommand 'funcregistrar' also formats help document of the function with the 'decl'(aration) specified at the construction. This can avoid (1) redundancy between 'decl' and help document, and (2) accidental typo of help document. For example, 'foo' should appear twice like below, if without such formatting: @keyword('foo') def foo(....): """:foo: Explanation of keyword foo ...""" Almost all cases needs very simple document formatting like below: - "``DECL``\n EXPLANATION" - ":DECL: EXPLANATION" But webcommand needs a little complicated formatting like: /PATH/SPEC ---------- EXPLANATION .... To make minirst recognize the section header, hyphen line should be as long as "/PATH/SPEC". It should be arranged by program. Implementing 'formatdoc()' in derived class can support complicated formatting in the latter case. But it seems redundant for simple one in the former case. Therefore, 'funcregistrar' does: - invoke 'self.formatdoc', if it is callable (for the latter case) - use it as the format string, otherwise (for the former case)

hgweb: support rendering a sub-topic If the requested topic contains a "." we assume a sub-topic is requested and display it.

hgweb: support rendering sub-topic indexes If the requested topic name is the name of a sub-topic, we now render an index of topics within that sub-topic.

templates: support linking to main help page Currently, the "helptopics" template assumes it is only used as the main index and therefore doesn't hyperlink "help" in the navigation list. Sub-topics will introduce an additional consumer of this template. So teach the template to hyperlink the "help" navigation entry when necessary.

templates: differentiate between partial and full topic name In order to support sub-topics, we need to support linking to a full topic name while displaying the base topic name. Change the {helpentry} template to grab the display name from an optional seperate variable (which will be defined in a future patch).

templates: make earlycommands and othercommands optional We now have sub-topics in the help system. The "helptopics" template serves as a mechanism for displaying an index of help topics. Previously, it was only used to show the top-level list of help topics, which includes special groupings of topics. In the near future, we'll adapt "helptopics" for showing the index of sub-topics. In this patch, we optionally render {earlycommands} and {othercommands} since they aren't present on sub-topics.

rebase: better error message when rebased changes are all in destination Before this patch, when rebasing a set of obsolete revisions that were plain pruned or already present in the destination, we were displaying: abort: no matching revisions This was not very helpful to understand what was going on, instead we replace the error message by: abort: all requested changesets have equivalents or were marked as obsolete (to force the rebase, set the config experimental.rebaseskipobsolete to False)

lrucachedict: add copy method This diff implements the standard dict copy() method for lrucachedicts, which will be used in the pushrebase extension to make a copy of the manifestcache.

Added signature for changeset ea389970c084

Added tag 3.6.3 for changeset ea389970c084

merge with i18n

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".