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.