[PATCH 4 of 8] transaction: avoid file stat ambiguity only for files in blacklist
Yuya Nishihara
yuya at tcha.org
Sun Jul 2 14:06:04 UTC 2017
On Fri, 30 Jun 2017 01:53:11 +0900, FUJIWARA Katsunori wrote:
> # HG changeset patch
> # User FUJIWARA Katsunori <foozy at lares.dti.ne.jp>
> # Date 1498754869 -32400
> # Fri Jun 30 01:47:49 2017 +0900
> # Node ID d4d47784511456e6cf77b194822f23586e052312
> # Parent 9114ae36f40b733912705ef0bacb2961941f18d6
> transaction: avoid file stat ambiguity only for files in blacklist
> diff --git a/mercurial/transaction.py b/mercurial/transaction.py
> --- a/mercurial/transaction.py
> +++ b/mercurial/transaction.py
> @@ -44,11 +44,12 @@ def active(func):
> return _active
>
> def _playback(journal, report, opener, vfsmap, entries, backupentries,
> - unlink=True):
> + unlink=True, noambigstatfiles=None):
> for f, o, _ignore in entries:
> if o or not unlink:
> + checkambig = noambigstatfiles and (f, '') in noambigstatfiles
> try:
> - fp = opener(f, 'a', checkambig=True)
> + fp = opener(f, 'a', checkambig=checkambig)
> fp.truncate(o)
> fp.close()
> except IOError:
> @@ -101,7 +102,8 @@ def _playback(journal, report, opener, v
>
> class transaction(object):
> def __init__(self, report, opener, vfsmap, journalname, undoname=None,
> - after=None, createmode=None, validator=None, releasefn=None):
> + after=None, createmode=None, validator=None, releasefn=None,
> + noambigstatfiles=None):
> """Begin a new transaction
>
> Begins a new transaction that allows rolling back writes in the event of
> @@ -110,6 +112,10 @@ class transaction(object):
> * `after`: called after the transaction has been committed
> * `createmode`: the mode of the journal file that will be created
> * `releasefn`: called after releasing (with transaction and result)
> +
> + `noambigstatfiles` is a set of (path, vfs-location) tuples,
> + which determine whether file stat ambiguity should be avoided
> + for corresponded files.
IIUC, this is a set of files that could get ambiguous, but "noambig" semed to
say the opposite.
Other than that, the code looks fine. FWIW, I'm getting a feeling that we've
failed to design a sensible cache-validation API because it's quite hard to
rely only on mtime/ctime.
More information about the Mercurial-devel
mailing list