Fri, 18 Jan 2013 23:43:32 +0100 repoview: cache filtered changelog
Pierre-Yves David <pierre-yves.david@logilab.fr> [Fri, 18 Jan 2013 23:43:32 +0100] rev 18445
repoview: cache filtered changelog Creating a new changelog object for each access is costly and prevents efficient caching changelog side. This introduced a x5 performance regression in log because chunk read from disk were never reused. We were jumping from about 100 disk read to about 20 000. This changeset introduce a simple cache mechanism that help the last changelog object created by a repoview. The changelog is reused until the changelog or the filtering changes. The cache invalidation is much more complicated than it should be. But MQ test show a strange cache desync. I was unable to track down the source of this desync in descent time so I'm not sure if the issue is in MQ or core. However given the proximity to the 2.5 freeze, I'm choosing the inelegant but safe route that makes the cache mechanism safer.
Fri, 18 Jan 2013 14:15:32 +0100 rebase: do not invent successor to skipped changeset
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 18 Jan 2013 14:15:32 +0100] rev 18444
rebase: do not invent successor to skipped changeset When rebase results in an empty a changeset it is "skipped" and no related changeset is created at all. When we added obsolescence support to rebase (in fc2a6114f0a0) it seemed a good idea to use its parent successor as the successors for such dropped changesets. (see old version of the altered test). This option was chosen because it seems a good way to hint about were the dropped changeset "intended" to be. Such hint would have been used by automatic evolution mechanism to rebase potential unstable children. However, field testing of this version are not conclusive. It very often leads to the creation of (totally unfounded) evolution divergence. This changeset changes this behavior and mark skipped changesets as pruned (obsolete without successors). This prevents the issue and seems semantically better probably a win for obsolescence reading tool. See example bellow for details: User Babar has five changesets of interest: - O, its current base of development. - U, the new upstream - A and C, some development changesets - B another development changeset independent from A O - A - B - C \ U Babar decides that B is more critical than the A and C and rebase it first $ hg rebase --rev B --dest U B is now obsolete (in lower case bellow). Rebase result, B', is its successors.(note, C is unstable) O - A - b - C \ U - B' Babar is now done with B', and want to rebase the rest of its history: $ hg rebase --source A --dest B' hg rebase process A, B and C. B is skipped as all its changes are already contained in B'. O - U - B' - A' - C' Babar have the expected result graph wise, obsolescence marker are as follow: B -> B' (from first rebase) A -> A' (from second rebase) C -> C' (from second rebase) B -> ?? (from second rebase) Before this changeset, the last marker is `B -> A'`. This cause two issues: - This is semantically wrong. B have nothing to do with A' - B has now two successors sets: (B',) and (A',). We detect a divergent rewriting. The B' and A' are reported as "divergent" to Babar, confusion ensues. In addition such divergent situation (divergent changeset are children to each other) is tricky to solve. With this changeset the last marker is `B -> ΓΈ`: - This is semantically better. - B has a single successors set (B',) This scenario is added to the tests suite.
Thu, 17 Jan 2013 17:51:30 +0100 repoview: protect `base` computation from weird phase root
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 17 Jan 2013 17:51:30 +0100] rev 18443
repoview: protect `base` computation from weird phase root If for some reason the phase roots contains nullid, the set of filtered revs will contains -1. That confuse Mercurial a lot. In particular this corrupt the branchcache. Standard code path does not result in nullid phase root. It can only result from altered `.hg/store/phaseroots` or buggy extension. However better safe than sorry.
Fri, 18 Jan 2013 15:55:16 -0800 posix: don't compare atime when determining if a file has changed
Siddharth Agarwal <sid0@fb.com> [Fri, 18 Jan 2013 15:55:16 -0800] rev 18442
posix: don't compare atime when determining if a file has changed A file's atime might change even if the file itself doesn't change. This might cause us to invalidate caches more often than necessary. Before this change, hg add often resulted in the dirstate being parsed twice on systems that track atime. After this change, it is only parsed once. For a repository with over 180,000 files, this speeds up hg add from 1.2 seconds to 1.0.
Fri, 05 Oct 2012 18:10:56 -0500 hg: replace DirCleanup class with normal try/finally use
Augie Fackler <raf@durin42.com> [Fri, 05 Oct 2012 18:10:56 -0500] rev 18441
hg: replace DirCleanup class with normal try/finally use
Wed, 16 Jan 2013 19:21:03 +0100 histedit: proper phase conservation (issue3724)
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 16 Jan 2013 19:21:03 +0100] rev 18440
histedit: proper phase conservation (issue3724) Before this changeset, histedit created all new changesets according phases.new-commit option without any regards for the phases of the original changesets. This changeset fix that using the phase of rewritten changeset to decide the phase of the resulting changeset. In case of reordering or folding, we keep secret item secret as it seems the safer path. temporary commit creation are not affected. They are head only and stripped at the end of the histedit. As for the resolution of issue3681 (obsolescence cycle prevention), we do not handle changesets created by edit command.
Wed, 16 Jan 2013 19:19:56 +0100 test-histedit: reorder phases test and prepare for more
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 16 Jan 2013 19:19:56 +0100] rev 18439
test-histedit: reorder phases test and prepare for more We are going to add a lot regarding phase of test while fixing issue3724. This movement allows to put them after this first phase test.
Wed, 16 Jan 2013 19:17:36 +0100 test-histedit: fix instability creation test
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 16 Jan 2013 19:17:36 +0100] rev 18438
test-histedit: fix instability creation test The current test does not rewrite anything and therefor does not create any instability. We also clean up the repo state after the test. This required the rebase extension.
Wed, 16 Jan 2013 19:14:22 +0100 histedit: record histedit source (issue3681)
Pierre-Yves David <pierre-yves.david@logilab.fr> [Wed, 16 Jan 2013 19:14:22 +0100] rev 18437
histedit: record histedit source (issue3681) Have histedit record the hex of the original changeset as already done by: - graft - commit --amend - rebase My main motivation for adding this is to prevent the creation of obsolescence cycle (see issue3681). Note that commit created during edit are not affected yet.
Wed, 16 Jan 2013 19:11:06 +0100 histedit: factor most commit creation in a function
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 16 Jan 2013 19:11:06 +0100] rev 18436
histedit: factor most commit creation in a function Later commits add two important items to histedit: - Obsolescence cycle prevention - Proper phase conservation Those logics must be applied to all simple operations (pick, edit, mess) and will require verbose code. So we introduce a new function that will provide an entry point for this new. logic. The function build a closure to have a clear distinction between commit arguments and data provided to the function to fulfil its logic.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip