Sat, 14 May 2016 13:39:33 +0900 import-checker: extend check of symbol-import order to all local modules
Yuya Nishihara <yuya@tcha.org> [Sat, 14 May 2016 13:39:33 +0900] rev 29208
import-checker: extend check of symbol-import order to all local modules It doesn't make sense that (a) is allowed whereas (b) is disallowed. a) from mercurial import hg from mercurial.i18n import _ b) from . import hg from .i18n import _
Sat, 14 May 2016 13:20:13 +0900 import-checker: always build a list of imported symbols
Yuya Nishihara <yuya@tcha.org> [Sat, 14 May 2016 13:20:13 +0900] rev 29207
import-checker: always build a list of imported symbols The next patch will rely on it.
Sat, 14 May 2016 13:49:46 +0900 import-checker: fix test to make a real package
Yuya Nishihara <yuya@tcha.org> [Sat, 14 May 2016 13:49:46 +0900] rev 29206
import-checker: fix test to make a real package Otherwise "testpackage" wouldn't be counted as a package when building a list of imported symbols.
Sat, 14 May 2016 14:03:12 +0900 py3: move up symbol imports to enforce import-checker rules
Yuya Nishihara <yuya@tcha.org> [Sat, 14 May 2016 14:03:12 +0900] rev 29205
py3: move up symbol imports to enforce import-checker rules Since (b) is banned, we should do the same for (a) for consistency. a) from mercurial import hg from mercurial.i18n import _ b) from . import hg from .i18n import _
Thu, 19 May 2016 00:20:38 +0900 util: make copyfile avoid ambiguity of file stat if needed
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 19 May 2016 00:20:38 +0900] rev 29204
util: make copyfile avoid ambiguity of file stat if needed In some cases below, copying from backup is used to restore original contents of a file. If copying keeps ctime, mtime and size of a file, restoring is overlooked, and old contents cached before restoring isn't invalidated as expected. - failure of transaction before closing (from '.hg/journal.backup.*') - rollback of previous transaction (from '.hg/undo.backup.*') To avoid such problem, this patch makes copyfile() avoid ambiguity of file stat, if needed. Ambiguity check is executed, only if: - checkambig=True is specified (not all copying needs ambiguity check), and - destination file exists before copying This patch also adds 'not (copystat and checkambig)' assertion, because combination of copystat and checkambig is meaningless. This patch is a part of preparation for "Exact Cache Validation Plan": https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan
Thu, 19 May 2016 00:20:38 +0900 vfs: make rename avoid ambiguity of file stat if needed
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 19 May 2016 00:20:38 +0900] rev 29203
vfs: make rename avoid ambiguity of file stat if needed In some cases below, renaming from backup is used to restore original contents of a file. If renaming keeps ctime, mtime and size of a file, restoring is overlooked, and old contents cached before restoring isn't invalidated as expected. - failure of transaction before closing (only from '.hg/journal.dirstate') - rollback of previous transaction (from '.hg/undo.*') - failure in dirstateguard scope (from '.hg/dirstate.SUFFIX') To avoid such problem, this patch makes vfs.rename() avoid ambiguity of file stat, if needed. Ambiguity check is executed, only if: - checkambig=True is specified (not all renaming needs ambiguity check), and - destination file exists before renaming This patch is a part of preparation for "Exact Cache Validation Plan": https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan
Thu, 19 May 2016 00:20:38 +0900 vfs: make atomictempfile avoid ambiguity of file stat if needed
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 19 May 2016 00:20:38 +0900] rev 29202
vfs: make atomictempfile avoid ambiguity of file stat if needed This patch is a part of preparation for "Exact Cache Validation Plan": https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan
Thu, 19 May 2016 00:20:38 +0900 util: make atomictempfile avoid ambiguity of file stat if needed
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 19 May 2016 00:20:38 +0900] rev 29201
util: make atomictempfile avoid ambiguity of file stat if needed Ambiguity check is executed at close(), only if: - atomictempfile is created with checkambig=True, and - target file exists before renaming This restriction avoids performance decrement by needless examination of file stat (for example, filelog doesn't need exact cache validation, even though it uses atomictempfile to write changes out). See description of filestat class for detail about why the logic in this patch works as expected. This patch is a part of preparation for "Exact Cache Validation Plan": https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan
Thu, 19 May 2016 00:20:37 +0900 util: add filestat class to detect ambiguity of file stat
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 19 May 2016 00:20:37 +0900] rev 29200
util: add filestat class to detect ambiguity of file stat Current posix.cachestat implementation might overlook change of a file, if changing keeps ctime, mtime and size of file. Comparison of inode number also overlooks changing in such situation, because inode number is rapidly reused. Contents of a file cached before changing isn't invalidated as expected, if change of a file is overlooked for this "ambiguity" of file stat. This patch adds filestat class to detect ambiguity of file stat. This patch is a part of preparation for "Exact Cache Validation Plan": https://www.mercurial-scm.org/wiki/ExactCacheValidationPlan
Thu, 05 May 2016 23:17:19 +0000 run-tests: handle json.dumps divergence
timeless <timeless@mozdev.org> [Thu, 05 May 2016 23:17:19 +0000] rev 29199
run-tests: handle json.dumps divergence In py2, json.dumps includes a trailing space after a comma at the end of lines. The py3 behavior which omits the trailing space is preferable, so we're going to strip it.
Tue, 10 May 2016 22:52:26 +0000 tests: use debuginstall to retrieve hg version
timeless <timeless@mozdev.org> [Tue, 10 May 2016 22:52:26 +0000] rev 29198
tests: use debuginstall to retrieve hg version
Tue, 10 May 2016 22:45:45 +0000 debuginstall: add mercurial version
timeless <timeless@mozdev.org> [Tue, 10 May 2016 22:45:45 +0000] rev 29197
debuginstall: add mercurial version
Thu, 12 May 2016 06:13:59 -0700 strip: invalidate phase cache after stripping changeset (issue5235) stable
Laurent Charignon <lcharignon@fb.com> [Thu, 12 May 2016 06:13:59 -0700] rev 29196
strip: invalidate phase cache after stripping changeset (issue5235) When we remove a changeset from the changelog, the phase cache must be invalidated, otherwise it could refer to changesets that are no longer in the repo. To reproduce the failure, I created an extension querying the phase cache after the strip transaction is over. To do that, I stripped two commits with a bookmark on one of them to force another transaction (we open a transaction for moving bookmarks) after the strip transaction. Without the fix in this patch, the test leads to a stacktrace showing the issue: repair.strip(ui, repo, revs, backup) File "/Users/lcharignon/facebook-hg-rpms/hg-crew/mercurial/repair.py", line 205, in strip tr.close() File "/Users/lcharignon/facebook-hg-rpms/hg-crew/mercurial/transaction.py", line 44, in _active return func(self, *args, **kwds) File "/Users/lcharignon/facebook-hg-rpms/hg-crew/mercurial/transaction.py", line 490, in close self._postclosecallback[cat](self) File "$TESTTMP/crashstrip2.py", line 4, in test [repo.changelog.node(r) for r in repo.revs("not public()")] File "/Users/lcharignon/facebook-hg-rpms/hg-crew/mercurial/changelog.py", line 337, in node return super(changelog, self).node(rev) File "/Users/lcharignon/facebook-hg-rpms/hg-crew/mercurial/revlog.py", line 377, in node return self.index[rev][7] IndexError: revlog index out of range The situation was encountered in inhibit (evolve's repo) where we would crash following the volatile set invalidation submitted by Augie in e6f490e328635312ee214a12bc7fd3c7d46bf9ce. Before his patch the issue was masked as we were not accessing the phasecache after stripping a revision. This bug uncovered another but in histedit (see explanation in issue5235). I changed the histedit test accordingly to avoid fixing two things at once.
Mon, 16 May 2016 04:31:20 +0530 py3: make tests/svn-safe-append.py use absolute_import
Pulkit Goyal <7895pulkit@gmail.com> [Mon, 16 May 2016 04:31:20 +0530] rev 29195
py3: make tests/svn-safe-append.py use absolute_import
Mon, 16 May 2016 04:28:22 +0530 py3: make tests/test-atomictempfile.py use absolute_import
Pulkit Goyal <7895pulkit@gmail.com> [Mon, 16 May 2016 04:28:22 +0530] rev 29194
py3: make tests/test-atomictempfile.py use absolute_import
Mon, 16 May 2016 04:08:17 +0530 py3: tests/test-check-py3-compat.t output updated
Pulkit Goyal <7895pulkit@gmail.com> [Mon, 16 May 2016 04:08:17 +0530] rev 29193
py3: tests/test-check-py3-compat.t output updated The lower part of the tests runs with Python 3.5 so its remains unchanged with new commits.
Tue, 17 May 2016 05:32:36 +0530 py3: use setattr() to assign new class attribute
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 17 May 2016 05:32:36 +0530] rev 29192
py3: use setattr() to assign new class attribute The old method produces error 'object does not supports item assignment'. So setattr() is used to assign a new class attribute via __dict__ .
Wed, 11 May 2016 14:18:52 -0700 localrepo: use dirstate savebackup instead of handling dirstate file manually
Mateusz Kwapich <mitrandir@fb.com> [Wed, 11 May 2016 14:18:52 -0700] rev 29191
localrepo: use dirstate savebackup instead of handling dirstate file manually This is one step towards having dirstate manage its own storage. It will be useful for the implementation of sql dirstate [1]. This introduced a small test change: now we always write the dirstate before saving backup so in some cases where dirstate file didn't exist yet savebackup can create it. [1] https://www.mercurial-scm.org/wiki/SQLDirstatePlan
Fri, 13 May 2016 13:30:08 -0700 localrepo: use dirstate restorebackup instead of copying dirstate manually
Mateusz Kwapich <mitrandir@fb.com> [Fri, 13 May 2016 13:30:08 -0700] rev 29190
localrepo: use dirstate restorebackup instead of copying dirstate manually This is one step towards having dirstate manage its own storage. It will be useful for the implementation of sqldirstate [1]. I'm deleting two of the dirstate.invalidate() calls in localrepo because restorebackup method does that for us. [1] https://www.mercurial-scm.org/wiki/SQLDirstatePlan
Fri, 13 May 2016 13:28:09 -0700 dirstate: add prefix and suffix arguments to backup
Mateusz Kwapich <mitrandir@fb.com> [Fri, 13 May 2016 13:28:09 -0700] rev 29189
dirstate: add prefix and suffix arguments to backup This would allow the code explicitly copying dirstate to use this method instead. Use of this method will increase encapsulation (the dirstate class will be sole owner of its on-disk storage).
Wed, 20 Apr 2016 19:55:59 +0000 tests: mark test-atomictempfile.py write as binary
timeless <timeless@mozdev.org> [Wed, 20 Apr 2016 19:55:59 +0000] rev 29188
tests: mark test-atomictempfile.py write as binary
Wed, 20 Apr 2016 19:53:01 +0000 tests: mark test-context.py write as binary
timeless <timeless@mozdev.org> [Wed, 20 Apr 2016 19:53:01 +0000] rev 29187
tests: mark test-context.py write as binary
Thu, 05 May 2016 16:20:53 +0200 transaction: turn lack of locking into a hard failure (API)
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 05 May 2016 16:20:53 +0200] rev 29186
transaction: turn lack of locking into a hard failure (API) We have been warning about transactions without locks for about a year (and three releases), third party extensions had a fair grace period to fix their code, we are moving lack of locking to a hard failure in order to protect users against repository corruption.
Thu, 05 May 2016 16:13:22 +0200 test: extract develwarn transaction testing in its own command
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 05 May 2016 16:13:22 +0200] rev 29185
test: extract develwarn transaction testing in its own command The lack of locking for a transation is about to change from a warning to an error. We first extract the test decidated to this warning to make the next changeset clearer.
(0) -10000 -3000 -1000 -300 -100 -50 -24 +24 +50 +100 +300 +1000 +3000 +10000 tip