py3: convert bool variables to bytes

context: avoid writing outdated dirstate out (issue5584) Before this patch, workingctx.status() may cause writing outdated dirstate out, if: - .hg/dirstate is changed simultaneously after last loading it, - there is any file, which should be dirstate.normal()-ed Typical issue case is: - the working directory is updated by "hg update" - .hg/dirstate is updated in background (e.g. fsmonitor) This patch compares identities of dirstate before and after acquisition of wlock, and avoids writing outdated dirstate out, if change of .hg/dirstate is detected.

tests: factor external procedures out for portability Fortunately, "&&" is treated as "execute next, if previous doesn't fail" both on POSIX and Windows. But keeping portability of "dirstaterace.command" manually is troublesome. This patch factors external procedures out as a shell script for portability. "sh SCRIPT" always allows scripting in POSIX style. This change is also for convenience. Fixed script name can reduce command line arguments. "r" prefix is needed for "sh '$TESTTMP/dirstaterace.sh'", because $TESTTMP contains backslash on Windows.

dirstate: add identity information to detect simultaneous changing in storage This identity is used to examine whether dirstate is simultaneously changed in storage after previous caching (see issue5584 for detail). util.cachestat can't be used for this purpose, because it has no valuable information on Windows. On the other hand, util.filestat can detect changing dirstate in storage certainly, regardless of platforms. https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan Strictly speaking, if underlying filesystem doesn't support ctime/mtime, util.filestat can't detect simultaneous changing in storage as expected. But simultaneous changing on such (very rare) platform can't be detected regardless of this patch series. Therefore, util.filestat should be reasonable identity for almost all usecases.

util: make filestat.__eq__ return True if both of self and old have None stat For convenience to compare two filestat objects regardless of None-ness of stat field.

vfs: create copy at renaming to avoid file stat ambiguity if needed In order to fix issue5418, bff5ccbe5ead made vfs.rename(checkambig=True) omit advancing mtime of renamed file, if renamed file is owned by another (EPERM is raised in this case). But this omission causes rewinding mtime at restoration in such situation, and makes avoiding file stat ambiguity difficult, because ExactCacheValidationPlan assumes that mtime should be advanced, if a file is changed in same ctime. https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan Ambiguity of file stat also requires issue5584 to be fixed with other than file stat, but "hash of file", "generation ID" and so on were already rejected ideas (please see original RFC linked from "Outline of issue" in ExactCacheValidationPlan page). This omission occurs: - only for non append-only files (dirstate, bookmarks, and phaseroots), and - only if previous transaction is rollbacked by another user The latter means "sharing a repository clone via group permission". This is reasonable usecase, but not ordinary for many users, IMHO. "hg rollback" itself has been deprecated since Mercurial 2.7, too. Therefore, increasing the cost at rollbacking previous transaction executed by another a little seems reasonable, for avoidance of file stat ambiguity. This patch does: - create copy of (already renamed) source file, if advancing mtime fails for EPERM - rename from copied file to destination file, and - advance mtime of renamed file, which is now owned by current user This patch also factors "self.join(src)" out to reduce redundancy.

vfs: factor out "rename and avoid ambiguity" to reuse This makes subsequent patch simple.

util: make filestat.avoidambig() return whether ambiguity is avoided or not

debugcommands: issue warning when repo has secret changesets (issue5589) This seems like a prudent thing to do. As the inline comment says, we may want to make this abort once the functionality is stabilized as part of `hg bundle`. Let's save that debate for another day.

streamclone: consider secret changesets (BC) (issue5589) Previously, a repo containing secret changesets would be served via stream clone, transferring those secret changesets. While secret changesets aren't meant to imply strong security (if you really want to keep them secret, others shouldn't have read access to the repo), we should at least make an effort to protect secret changesets when possible. After this commit, we no longer serve stream clones for repos containing secret changesets by default. This is backwards incompatible behavior. In case anyone is relying on the behavior, we provide a config option to opt into the old behavior. Note that this defense is only beneficial for remote repos accessed via the wire protocol: if a client has access to the files backing a repo, they can get to the raw data and see secret revisions.