subrepo: sanitize non-hg subrepos

shelve: fix bad argument interaction with largefiles (issue4111)

strip.stripcmd: remove redundant wlock acquire/release Now that we acquire and release a wlock in the outer scope, this is redundant.

merge with stable

bookmarks: make setcurrent with None an error

strip: use bookmarks.unsetcurrent instead of setcurrent with None

bmstore.write: use unsetcurrent instead of setcurrent with None

commands.bookmark: use unsetcurrent instead of setcurrent with None There are currently two different ways we can have no active bookmark: .hg/bookmarks.current being missing and it being an empty file. This patch and upcoming ones make an empty file the only way to represent no active bookmarks. This is the right choice because it matches the state that a new repository without bookmarks will be in.

strip: hold wlock for entire duration Previously, we'd acquire and release the wlock several times. This meant that other hg processes could come in and change state. Instead of that, retain the wlock for the entire duration of the strip.

merge with stable

bisect: report "both good and bad" as such, not as "not directly related"

phase: better error message when --force is needed When trying to turn a draft changeset into a secret changeset, I was told: % hg phase -s . cannot move 1 changesets to a more permissive phase, use --force no phases changed That message struck me as being backwards -- the secret phase feels less permissive to me since it restricts the changesets from being pushed. We don't use the word "permissive" elsewhere, 'hg help phase' talks about "lower phases" and "higher phases". I therefore reformulated the error message to be cannot move 1 changesets to a higher phase, use --force That is not perfect either, but more in line with the help text. An alternative could be cannot move phase backwards for 1 changesets, use --force which fits better with the help text for --force.

hgweb: ignore non numeric "revcount" parameter values (issue4091)

lock: take both vfs and lock file path relative to vfs to access via vfs This patch makes "lock.lock.__init__()" take both vfs and lock file path relative to vfs, instead of absolute path to lock file. This allows lock file to be accessed via vfs.

vfs: add "makelock()" and "readlock()"

hg: rewrite "copystore()" with vfs This patch rewrites "copystore()" with vfs, because succeeding patch requires "lock.lock()" invocation with vfs. This patch uses 'dstbase + "/lock"' instead of "join()" with both elements even on Windows environment but it should be reasonable, because target files given from "store.copyfiles()" already uses "/" as path separator. "util.copyfiles()" between two vfs-s may have to be rewritten in the future.

localrepo: import "lock" module as "lockmod" for readability Before this patch, "localrepo.py" has many methods defining local variable "lock", even though it imports "lock" module as "lock". This ambiguity decreases readability.

transaction: take journal file path relative to vfs to use file API via vfs

vfs: add "chmod()"

vfs: add "isfile()"

transaction: unlink target file via vfs Before this patch, unlink target file is once opened before unlinking, because "opener" before vfs migration doesn't have "unlink()" function. This patch uses "vfs.unlink()" instead of "open()" and "fp.name".

relink: abort earlier when on different devices (issue3916) Add a first check of the devices before collecting candidate files. This is much quicker when big repos are on different devices. Keep the existing check in prune. It checks for same device of the files. This could probably be different in a special repo store (with symlinks).

localrepo: prevent to copy repo local config, copy baseui instead Copying a repos local configuration to another repo is a bad idea because the 2nd repo gets the configuration of the first. Prevent this by really calling repo.baseui.copy when repo.ui.copy is called. This requires some changes in commandserver which needs to clone repo.ui for rejecting temporary changes. This patch has its roots back in the topic "repo isolation" around f0564402d059 and was suggested by mpm.

doc: show details of command options in pages generated by docutils Before this patch, HTML/man pages generated by docutils don't show details of each command options, whether it should take argument or not for example, even though "hg help" does. This patch shows details of command options as same as "hg help" shows. This patch uses "--option <VALUE[+]>" style instead of "--option <VALUE> [+]" used in output of "hg help", because docutils requires that option argument strings starts with "<" and ends with ">".