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.

histedit: extract bookmark logic in a dedicated function This lighten the main function and will help to see future changes to this bookmark logic.

histedit: remove all usages of hex[:12] - `node.hex(n)[:12]` is the same as `node.short(n)` - `ctx.hex()[:12]` is the same as `str(ctx)`

merge with stable

merge with i18n

largefiles: enable islfilesrepo() prior to a commit (issue3541) Previously, even if a file was added with --large, 'hg addremove' or 'hg ci -A' would add all files (including the previously added large files) as normal files. Only after a commit where a file was added with --large would subsequent adds or 'ci -A' take into account the minsize or the pattern configuration. This change more closely follows the help for largefiles, which mentions that 'add --large' is required to enable the configuration, but doesn't mention the previously required commit. Also, if 'hg add --large' was performed and then 'hg forget <file>' (both before a largefile enabling commit), the forget command would error out saying '.hglf/<file> not tracked'. This is also fixed. This reports that a repo is largefiles enabled as soon as a file is added with --large, which enables 'add', 'addremove' and 'ci -A' to honor the config settings before the first commit. Note that prior to the next commit, if all largefiles are forgotten, the repository goes back to reporting the repo as not largefiles enabled. It makes no sense to handle this by adding a --large option to 'addremove', because then it would also be needed for 'commit', but only when '-A' is specified. While this gets around the awkwardness of having to add a largefile, then commit it, and then addremove the other files when importing an existing codebase (and preserving that extra commit in permanent history), it does still require finding and manually adding one of the files as --large. Therefore it is probably desirable to have a --large option for init as well.

largefiles: handle commit -A properly, after a --large commit (issue3542) Previous to this, 'commit -A' would add as normal files, files that were already committed as largefiles, resulting in files being listed twice by 'status -A'. It also missed when (only) a largefile was deleted, even though status reported it as '!'. This also has the side effect of properly reporting the state of the affected largefiles in the post commit hook after a remove that also affected a normal file (the largefiles used to be 'R', now are properly absent). Since scmutil.addremove() is called both by the ui command (after some trivial argument validation) and during the commit process when -A is specified, it seems like a more appropriate method to wrap than the addremove command. Currently, a repo is only enabled to use largefiles after an add that explicitly identifies some file as large, and a subsequent commit. Therefore, this patch only changes behavior after such a largefile enabling commit. Note that in the test, if the final commit had a '-v', 'removing large8' would be printed twice. Both of these originate in removelargefiles(). The first print is in verbose mode after traversing remove + forget, the second is because the '_isaddremove' attr is set and 'after' is not.