Fri, 02 Jun 2017 16:57:21 +0530 py3: convert bool variables to bytes
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 02 Jun 2017 16:57:21 +0530] rev 32753
py3: convert bool variables to bytes
Fri, 09 Jun 2017 13:07:49 +0900 context: avoid writing outdated dirstate out (issue5584)
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 09 Jun 2017 13:07:49 +0900] rev 32752
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.
Fri, 09 Jun 2017 13:07:49 +0900 tests: factor external procedures out for portability
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 09 Jun 2017 13:07:49 +0900] rev 32751
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.
Fri, 09 Jun 2017 13:07:48 +0900 dirstate: add identity information to detect simultaneous changing in storage
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 09 Jun 2017 13:07:48 +0900] rev 32750
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.
Fri, 09 Jun 2017 13:07:48 +0900 util: make filestat.__eq__ return True if both of self and old have None stat
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 09 Jun 2017 13:07:48 +0900] rev 32749
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.
Fri, 09 Jun 2017 12:58:18 +0900 vfs: create copy at renaming to avoid file stat ambiguity if needed
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 09 Jun 2017 12:58:18 +0900] rev 32748
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.
Fri, 09 Jun 2017 12:58:18 +0900 vfs: factor out "rename and avoid ambiguity" to reuse
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 09 Jun 2017 12:58:18 +0900] rev 32747
vfs: factor out "rename and avoid ambiguity" to reuse This makes subsequent patch simple.
Fri, 09 Jun 2017 12:58:17 +0900 util: make filestat.avoidambig() return whether ambiguity is avoided or not
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 09 Jun 2017 12:58:17 +0900] rev 32746
util: make filestat.avoidambig() return whether ambiguity is avoided or not
Fri, 09 Jun 2017 10:42:19 -0700 debugcommands: issue warning when repo has secret changesets (issue5589)
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 09 Jun 2017 10:42:19 -0700] rev 32745
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.
Fri, 09 Jun 2017 10:41:13 -0700 streamclone: consider secret changesets (BC) (issue5589)
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 09 Jun 2017 10:41:13 -0700] rev 32744
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.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip