FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 09 Jun 2017 12:58:18 +0900] rev 32768
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.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 09 Jun 2017 12:58:18 +0900] rev 32767
vfs: factor out "rename and avoid ambiguity" to reuse
This makes subsequent patch simple.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 09 Jun 2017 12:58:17 +0900] rev 32766
util: make filestat.avoidambig() return whether ambiguity is avoided or not
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 09 Jun 2017 10:42:19 -0700] rev 32765
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.
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 09 Jun 2017 10:41:13 -0700] rev 32764
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.
Yuya Nishihara <yuya@tcha.org> [Fri, 09 Jun 2017 21:33:15 +0900] rev 32763
json: pass formatting options recursively
This bug was introduced in 654e9a1c8a6c. It's okay to escape <>, but is
unnecessary for command output.