store: optimize _pathencode by checking the length of the unencoded path If the input path is already longer than _maxstorepathlen, then we can skip doing the basic encoding (encodedir, _encodefname and _auxencode) and directly proceed to the hashed encoding. Those encodings, if at all, will make the path only longer.

pathencode: skip encoding if input is already longer than maxstorepathlen Calling basicencode may make the path longer, never shorter. If it's already too long before, then we don't even need to basicencode it.

pathencode: simplify basicencode

test-hybridencode: in practice, extensions aren't really unbound in length due to the fact that we only get to encode files ending in .i and .d inside the store

Merge

histedit-test: clarify the reason of a failure There is multiple conflict during this test. This add a small comment that highligh the reason of a particular failure.

histedit-test: make test-fold more verbose This helps to check the validity of fold result and debug potential issue.

bookmarks: teach the -r option to use revsets

help: add example of paths other than default in hgrc

i18n-ja: synchronized with f36f11f2bfce

merge with stable

lock: fixed race condition in trylock/testlock (issue3506) Suppose the following scenario: 1. Process A takes the lock (e.g. on commit). 2. Process B wants to grab the lock. Since lock file exists the exception is raised. In the catch block the testlock function is called. 3. Process A releases the lock. 4. Process B tries to read the lock file as a part of testlock function. This results in OSError (ENOENT) and since we're not inside the exception handler function this is propagated and aborts the whole operation. To fix this we now check in testlock function whether lock file actually exists and if not (i.e. if readlock fails) we just return.

scmutil: backout 83785bb56062 (issue3643)

help: removing trailing spaces

Merge with stable

test-largefiles.t: fix find quirk on OSX For some reason, find utility seems to preserve the trailing slash and append a new one on OSX: $ find somedir/ somedir/ somedir//somefile

clfilter: introduce `filteredrevs` attribute on changelog This changeset allows changelog object to be "filtered". You can assign a set of revision numbers to the `changelog.filteredrevs` attributes. The changelog will then pretends these revision does not exists in this repo. A few methods need to be altered to achieve this behavior: - tip - __iter_ - irevs - hasnode - headrevs For consistency and to help debugging, the following methods are altered too. Tests tend to show it's not necessary to alter them but have them raise proper exception helps to detect bad acces to filtered revisions. - rev - node - linkrev - parentrevs - flags The following methods would also need alteration for consistency purpose but this is non-trivial and not done yet. - nodemap - strip The C version of headrevs is not run if there is any revision to filter. It'll need a proper rewrite later to restore performance.

clfilter: remove any explicit revision number from default cmdutil range Revision "0" and "-1" may be filtered, we can't use them in any default revrange.

clfilter: remove usage of `range` in favor of iteration over changelog If we want to apply filtering at changelog level, we need to iterate over it. See previous changeset description for details.

clfilter: split `revlog.headrevs` C call from python code Make the pure python implementation of headrevs available to derived classes. It is important because filtering logic applied by `revlog` derived class won't have effect on `index`. We want to be able to bypass this C call to implement our own.

clfilter: handle non contiguous iteration in `revlov.headrevs` This prepares changelog level filtering. We can't assume that any revision can be heads because filtered revisions need to be excluded. New algorithm: - All revisions now start as "non heads", - every revision we iterate over is made candidate head, - parents of iterated revisions are definitely not head. Filtered revisions are never iterated over and never considered as candidate head.

clfilter: make the revlog class responsible of all its iteration This prepares changelog level filtering. We need the algorithms used in revlog to work on a subset of revisions. To achieve this, the use of explicit range of revision is banned. `range` and `xrange` calls are replaced by a `revlog.irevs` method. Filtered super class can then overwrite the `irevs` method to filter out revision.

clfilter: introduce a `hassecret` function We can only use copy clone if the cloned repo do not have any secret changeset. The current method for that is to run the "secret()" revset on the remote repo. But with proper filtering of hidden or unserved revision by the remote this revset won't return any revision even if some exist remotely. This changeset adds an explicit function to know if a repo have any secret revision or not. The other option would be to disable filtering for the query but I prefer the approach above, lighter both regarding code and performance.

filter: `updatebranchcache` during `addchangegroup` instead of after lock The forced recomputation of the branch cache was introduced by `ee317dbfb9d0`. Back there, `addchangegroup` did not handle any lock logic. Later `ee1ed6afac21` introduced lock logic to `addchangegroup`. Its description does not explain why the `updatebranchcache` call is made outside locking. I believe that the lock was released there because it fit well with the transaction release already in the code. Finally `926a06f7a353` moved all "unlocked" code of `addchangegroup` to an `repo._afterlock` callback. I do not think that the call to `updatebranchcache()` requires to be done outside locking. That may even be a bad idea to do so. Bringing this call back in the `addchangegroup` function makes the flow simpler and eases the following up changelog level filtering business.

lock-checker: new contrib extension based on work done by Mads This makes it possible to do lock validation as part of a normal test run. I didn't attempt any wlock validation because that's a bit more subtle to detect properly. Thanks to the initial patch from Mads for the idea.

resolve: commit the changes after each item resolve (issue3638) At the moment the resolve command doesn't save progress during the resolve process. In example if you try to resolve 100 conflicting files and interrupt the process (e.g., you close the external merge tool) after resolving 50 files you'll end up with 100 unresolved conflicts. Saving the progress helps a lot with long going merges. It's easy to achieve same behavior with simple script that calls resolve command for each unresolved file but it makes sense to make such behavior a default

bookmarks: rename arguments/variables for source code readability Before this patch, the argument bound to the source repository of incoming bookmarks for "bookmarks.diff()" is named as "remote". But in "hg outgoing" case, this argument is bound to local repository object. In addition to it, "local"/"remote" seem to mean not the direction of propagation of bookmarks, but just the location of cooperative repositories. To indicate the direction of propagation of bookmarks clearly on the source code, this patch uses "d(st)" and "s(rc)" combination instead of "l(ocal)" and "r(emote)" one. - "repo" and "remote" arguments are renamed to "dst" and "src" - "lmarks" and "rmarks" variables are renamed to "dmarsk" and "smarks"

histedit: move `continue` logic into a dedicated function When histedit "continue", there is several complicated logic to apply in order to detect intermediate changeset and concluded pending operation. This changeset extract this logic in a dedicated function to lighten the main one. No alteration to the logic is done.

histedit: rename `tip` to `topmost` I expected `tip` to be repo's tip when it was the rewritten set tip. I rename the variable to the less ambiguous `topmost`.

histedit: factorise node stripping logic Create a function dedicated to stripping a group of node. All existing duplicated code is replaced by call to this function. This new function take care of stripping known and relevant node only.