Thu, 13 Sep 2018 19:22:03 +0200 stablesortcache: update the variable tracking on-disk state after write stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 13 Sep 2018 19:22:03 +0200] rev 4104
stablesortcache: update the variable tracking on-disk state after write Since we updated the on disk content, we should update that value. In practice the object will likely be discarded after the write, but there is nothing wrong in being more correct.
Thu, 13 Sep 2018 19:22:39 +0200 stablesortcache: ignore permission and OS errors when writing stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 13 Sep 2018 19:22:39 +0200] rev 4103
stablesortcache: ignore permission and OS errors when writing This cache is related to the obshashrange one and we update it lazily by default. This can be an issue when pulling locally from a read only repository that was not configured for a more aggressive cache warming. The raised permission error was uncaught and could crash the whole process. Errors during cache update should not block Mercurial operations.
Thu, 13 Sep 2018 19:09:48 +0200 firstmergecache: update the variable tracking on-disk state after write stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 13 Sep 2018 19:09:48 +0200] rev 4102
firstmergecache: update the variable tracking on-disk state after write Since we updated the on disk content, we should update that value. In practice the object will likely be discarded after the write, but there is nothing wrong in being more correct.
Thu, 13 Sep 2018 17:08:18 +0200 firstmergecache: ignore permission and OS errors when writing stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 13 Sep 2018 17:08:18 +0200] rev 4101
firstmergecache: ignore permission and OS errors when writing This cache is related to the obshashrange one and we update it lazily by default. This can be an issue when pulling locally from a read only repository that was not configured for a more aggressive cache warming. The raised permission error was uncaught and could crash the whole process. Errors during cache update should not block Mercurial operations.
Thu, 13 Sep 2018 18:56:04 +0200 depthcache: update the variable tracking on disk state after write stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 13 Sep 2018 18:56:04 +0200] rev 4100
depthcache: update the variable tracking on disk state after write Since we updated the on disk content, we should update that value. In practice the object will likely be discarded after the write, but there is nothing wrong in being more correct.
Thu, 13 Sep 2018 17:08:05 +0200 depthcache: ignore permission and OS errors when writing stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 13 Sep 2018 17:08:05 +0200] rev 4099
depthcache: ignore permission and OS errors when writing This cache is related to the obshashrange one and we update it lazily by default. This can be an issue when pulling locally from a read only repository that was not configured for a more aggressive cache warming. The raised permission error was uncaught and could crash the whole process. Errors during Cache update should not block Mercurial operations.
Thu, 13 Sep 2018 18:20:50 +0200 obscache: update the variable tracking on disk state after write stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 13 Sep 2018 18:20:50 +0200] rev 4098
obscache: update the variable tracking on disk state after write Since we updated the on disk content, we should update that value. In practice the object will likely be discarded after the write, but there is nothing wrong in being more correct.
Thu, 13 Sep 2018 18:21:07 +0200 obscache: ignore permission and OS errors when writing stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 13 Sep 2018 18:21:07 +0200] rev 4097
obscache: ignore permission and OS errors when writing In practice we always update this cache along side a new transaction, with lock taken so permission issues should not happens. However, staying on the safe side is better. Errors during Cache update should not block Mercurial operations.
Thu, 13 Sep 2018 02:49:58 +0200 obshashrange: force reset if many changes stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 13 Sep 2018 02:49:58 +0200] rev 4096
obshashrange: force reset if many changes If there is many new markers (or the markers affect many changesets) resetting affected changeset can get slow. A common case for that is then changeset and markers are added in different transaction, (eg: when using clone bundle). When we detect such case, we reset the obshashrange cache, rewarming it should be faster. Here many is arbitrarily set to 10 000. The number might get adjusted.
Tue, 04 Sep 2018 19:30:19 +0800 topic: refactor revset.py slightly
Anton Shestakov <av6@dwimlabs.net> [Tue, 04 Sep 2018 19:30:19 +0800] rev 4095
topic: refactor revset.py slightly Checking both kind == 'literal' and topic.startswith('literal:') seems to be redundant, because of how stringutil.stringmatcher() works.
(0) -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 tip