changelog: specify checkambig=True to revlog.__init__, to avoid ambiguity If steps below occurs at "the same time in sec", all of mtime, ctime and size are same between (1) and (3). 1. append data to 00changelog.i (and close transaction) 2. discard appended data by truncation (strip or rollback) 3. append same size but different data to 00changelog.i again Therefore, cache validation doesn't work after (3) as expected. To avoid such file stat ambiguity around truncation, this patch specifies checkambig=True to revlog.__init__(). This makes revlog write changes out with checkambig=True. Even though changes of 00changelog.i themselves are written out at changelog._finalize(), this checkambig=True is needed, because revlog.checkinlinesize(), which is invoked at the end of changelog._finalize(), might replace already changed 00changelog.i by converted one. Even after this patch, avoiding file stat ambiguity of 00changelog.i around truncation isn't yet completed, because truncation side isn't aware of this issue. This is a part of ExactCacheValidationPlan. https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan

changelog: specify checkambig=True to avoid ambiguity around truncation If steps below occurs at "the same time in sec", all of mtime, ctime and size are same between (1) and (3). 1. append data to 00changelog.i (and close transaction) 2. discard appended data by truncation (strip or rollback) 3. append same size but different data to 00changelog.i again Therefore, cache validation doesn't work after (3) as expected. To avoid such file stat ambiguity around truncation, this patch specifies checkambig=True for renaming or opening to write changes out at finalization. Even after this patch, avoiding file stat ambiguity of 00changelog.i around truncation isn't yet completed, because truncation side isn't aware of this issue. This is a part of ExactCacheValidationPlan. https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan

manifest: specify checkambig=True to revlog.__init__, to avoid ambiguity If steps below occurs at "the same time in sec", all of mtime, ctime and size are same between (1) and (3). 1. append data to 00manifest.i (and close transaction) 2. discard appended data by truncation (strip or rollback) 3. append same size but different data to 00manifest.i again Therefore, cache validation doesn't work after (3) as expected. To avoid such file stat ambiguity around truncation, this patch specifies checkambig=True to revlog.__init__(). This makes revlog write changes out with checkambig=True. Even after this patch, avoiding file stat ambiguity of 00manifest.i around truncation isn't yet completed, because truncation side isn't aware of this issue. This is a part of ExactCacheValidationPlan. https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan

revlog: specify checkambig at writing to avoid file stat ambiguity This allows revlog-style files to be written out with checkambig=True easily. Because avoiding file stat ambiguity is needed only for filecache-ed manifest and changelog, this patch does: - use False for default value of checkambig - focus only on writing changes of index file out This patch also adds optional argument checkambig to _divert/_delay for changelog, to safely accept checkambig specified in revlog layer. But this argument can be fully ignored, because: - changes are written into other than index file, if name != target - changes are never written into index file, otherwise (into pending file by _divert, or into in-memory buffer by _delay) This is a part of ExactCacheValidationPlan. https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan

vfs: use checkambigatclosing in checkambig=True but atomictemp=False case In Mercurial source tree, opening a file in "a"/"a+" mode like below doesn't specify atomictemp=True for vfs, and this avoids file stat ambiguity check by atomictempfile. - writing changes out in revlog layer uses "a+" mode - truncation in repair.strip() uses "a" mode - truncation in transaction._playback() uses "a" mode If steps below occurs at "the same time in sec", all of mtime, ctime and size are same between (1) and (3). 1. append data to revlog-style file (and close transaction) 2. discard appended data by truncation (strip or rollback) 3. append same size but different data to revlog-style file again Therefore, cache validation doesn't work after (3) as expected. This patch uses checkambigatclosing in checkambig=True but atomictemp=False case, to check (and get rid of) file stat ambiguity at closing. This is a part of ExactCacheValidationPlan. https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan

scmutil: add file object wrapper class to check ambiguity at closing In Mercurial source tree, opening a file in "a"/"a+" mode like below doesn't specify atomictemp=True for vfs, and this avoids file stat ambiguity check by atomictempfile. - writing changes out in revlog layer uses "a+" mode - truncation in repair.strip() uses "a" mode - truncation in transaction._playback() uses "a" mode If steps below occurs at "the same time in sec", all of mtime, ctime and size are same between (1) and (3). 1. append data to revlog-style file (and close transaction) 2. discard appended data by truncation (strip or rollback) 3. append same size but different data to revlog-style file again Therefore, cache validation doesn't work after (3) as expected. This patch adds file object wrapper class checkambigatclosing to check (and get rid of) ambiguity at closing. It is used by vfs in subsequent patch. This is a part of ExactCacheValidationPlan. https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan BTW, checkambigatclosing is tested in test-filecache.py, even though it doesn't use filecache itself, because filecache assumes that file stat ambiguity never occurs (and there is no another test-*.py related to filecache).

scmutil: factor out common logic of delayclosedfile to reuse it This is a preparation for the subsequent patch, which adds another proxy class for a file object.

spartan: remove unused templates

monoblue: remove unused templates

gitweb: remove unused templates