Fri, 05 Jan 2018 04:26:59 +0100 caches: add a 'auto' option for obshashrange cache warming
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 05 Jan 2018 04:26:59 +0100] rev 3368
caches: add a 'auto' option for obshashrange cache warming This option will only warm the cache when used as a server.
Fri, 05 Jan 2018 04:26:51 +0100 caches: extract some config reading in 'shouldwarmcache'
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 05 Jan 2018 04:26:51 +0100] rev 3367
caches: extract some config reading in 'shouldwarmcache'
Fri, 05 Jan 2018 03:35:07 +0100 caches: pass the transaction to the "shouldwarncache" logic
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 05 Jan 2018 03:35:07 +0100] rev 3366
caches: pass the transaction to the "shouldwarncache" logic This will allow to have smarter mode about cache warming (eg: only warm them for server transaction.
Fri, 05 Jan 2018 22:17:27 +0100 caches: record 'desc' attribute on transaction
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 05 Jan 2018 22:17:27 +0100] rev 3365
caches: record 'desc' attribute on transaction This is useful to know if a transaction if server side or not.
Fri, 05 Jan 2018 04:37:49 +0100 caches: protect against missing connection
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 05 Jan 2018 04:37:49 +0100] rev 3364
caches: protect against missing connection If the connection cannot be established, we should not try to use it.
Wed, 27 Dec 2017 05:01:30 +0530 evolve: don't show working directory obsolete message if we were on it stable
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 27 Dec 2017 05:01:30 +0530] rev 3363
evolve: don't show working directory obsolete message if we were on it This patch tweaks showing wc obsolete message functionality to not show the message if the operation led us to the same changeset we were on before and it didn't obsoleted it. This make failed updates, update on current changeset and a pull with no change omit showing the message. This has some cons like if you are on rev 1 which is obsolete and you do `hg up <revset>` where revset is some revset which resolves to the rev 1, we won't show the warning as shown earlier.
Thu, 28 Dec 2017 03:12:54 +0530 prev: jump to parent's successor if parent is obsolete and topic is involved stable
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 28 Dec 2017 03:12:54 +0530] rev 3362
prev: jump to parent's successor if parent is obsolete and topic is involved `hg stack` shows a linear chain of commits even when they are not linear chain and some changesets are obsoleted and have successors as separate head. This is very nice to have a post evolution view of the stack. However when `hg prev` is run on an unstable changeset whose parent is obsolete and does not topic but parents successor has the topic, it shows no parent on the topic. This patch makes `hg prev` update to parent's successor and make things follow the stack order.
Thu, 28 Dec 2017 03:08:22 +0530 tests: add a test showing wrong behaviour doing `hg prev` on orphan cset stable
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 28 Dec 2017 03:08:22 +0530] rev 3361
tests: add a test showing wrong behaviour doing `hg prev` on orphan cset If there is an unstable changeset in the topic stack, whose parent is not a part of stack but has a successor which is part of stack, hg stack does shows them in linear order, but `hg prev` on that orphan changset says no parent on that topic. However it should update to the successor of the changeset. It will be fixed in the next patch.
Fri, 05 Jan 2018 09:51:07 +0100 test: update output to 02fdb8c018aa
Boris Feld <boris.feld@octobus.net> [Fri, 05 Jan 2018 09:51:07 +0100] rev 3360
test: update output to 02fdb8c018aa Now that we have directaccess in core, we get a new warning message when updating to a hidden changeset. Update the tests. CORE-TEST-OUTPUT-UPDATE: 02fdb8c018aa
Fri, 05 Jan 2018 09:23:09 +0100 test: update output to 9b3f95d9783d
Boris Feld <boris.feld@octobus.net> [Fri, 05 Jan 2018 09:23:09 +0100] rev 3359
test: update output to 9b3f95d9783d The unstable graph nodes are now shown with the character "*", update the test outputs. CORE-TEST-OUTPUT-UPDATE: 9b3f95d9783d
Thu, 21 Dec 2017 06:12:02 +0100 stablesort: use parent filtering in a place we forgot to
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 21 Dec 2017 06:12:02 +0100] rev 3358
stablesort: use parent filtering in a place we forgot to Freak merge striked again.
Thu, 21 Dec 2017 06:18:50 +0100 obshashrange: add a progressbar to upgrade
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 21 Dec 2017 06:18:50 +0100] rev 3357
obshashrange: add a progressbar to upgrade This section is the slowest, have some progress idea would be useful.
Thu, 21 Dec 2017 04:29:02 +0100 stablerange: add an sql index on subranges id too
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 21 Dec 2017 04:29:02 +0100] rev 3356
stablerange: add an sql index on subranges id too This should speed up query that find super ranges.
Thu, 21 Dec 2017 04:14:05 +0100 obshashrange: less brutal reset when receiving markers on existing node
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 21 Dec 2017 04:14:05 +0100] rev 3355
obshashrange: less brutal reset when receiving markers on existing node We now target the affected ranges only. The implementation is still slow but that should be better than what we had before.
Thu, 21 Dec 2017 04:39:45 +0100 obshashrange: update the cache updating logic
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 21 Dec 2017 04:39:45 +0100] rev 3354
obshashrange: update the cache updating logic Use the more modern option when available. (Same as the other caches).
Thu, 21 Dec 2017 04:24:37 +0100 stablerange: cleanup the update logic
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 21 Dec 2017 04:24:37 +0100] rev 3353
stablerange: cleanup the update logic
Thu, 21 Dec 2017 04:23:45 +0100 stablesort: cleanup the update logic
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 21 Dec 2017 04:23:45 +0100] rev 3352
stablesort: cleanup the update logic
Thu, 21 Dec 2017 04:22:36 +0100 firstmergecache: cleanup the update logic
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 21 Dec 2017 04:22:36 +0100] rev 3351
firstmergecache: cleanup the update logic
Thu, 21 Dec 2017 04:21:53 +0100 depthcache: cleanup the update logic
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 21 Dec 2017 04:21:53 +0100] rev 3350
depthcache: cleanup the update logic
Thu, 21 Dec 2017 04:12:02 +0100 changelog: add an entry about the obshashrange changes
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 21 Dec 2017 04:12:02 +0100] rev 3349
changelog: add an entry about the obshashrange changes
Thu, 21 Dec 2017 04:35:40 +0100 stablerange: be more cautious when deleting the sql connection
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 21 Dec 2017 04:35:40 +0100] rev 3348
stablerange: be more cautious when deleting the sql connection This triggered some crash in further development. This also match what is done elsewhere with this attribute.
Thu, 21 Dec 2017 03:42:54 +0100 stablerange: clarify sql transaction logic
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 21 Dec 2017 03:42:54 +0100] rev 3347
stablerange: clarify sql transaction logic This should help concurrent access.
Thu, 21 Dec 2017 03:30:13 +0100 stablerange: use mergepoint based algorithm for the official stable range
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 21 Dec 2017 03:30:13 +0100] rev 3346
stablerange: use mergepoint based algorithm for the official stable range Changing the official stable range will impact all users of the infrastructure. We update version number of the cache file and discovery methods to clarify this. We do no keep compatibility with the old method over the wire. The new algorithm is much better and keeping compat is more work than we have time for right now.
Thu, 21 Dec 2017 03:07:14 +0100 stablerange: explicitly create a stablerange entry for branchpoint method
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 21 Dec 2017 03:07:14 +0100] rev 3345
stablerange: explicitly create a stablerange entry for branchpoint method We are about to change the default.
Mon, 18 Dec 2017 02:17:29 +0100 stablerange: have a mergepoint based sql backed class
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 18 Dec 2017 02:17:29 +0100] rev 3344
stablerange: have a mergepoint based sql backed class Everything is so generic that getting a class is 3 line of codes.
Mon, 18 Dec 2017 02:11:34 +0100 stablerange: introduce a sql backed version of the generic on disk cache
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 18 Dec 2017 02:11:34 +0100] rev 3343
stablerange: introduce a sql backed version of the generic on disk cache This is getting use close to actually using the new sorting and algorithm for real.
Mon, 18 Dec 2017 01:11:01 +0100 stablerange: add a base class for on disk stored stablerange class
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 18 Dec 2017 01:11:01 +0100] rev 3342
stablerange: add a base class for on disk stored stablerange class
Thu, 21 Dec 2017 02:13:19 +0100 stablesort: use on disk cache for test
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 21 Dec 2017 02:13:19 +0100] rev 3341
stablesort: use on disk cache for test
Thu, 21 Dec 2017 02:01:58 +0100 caches: factorise the cache warming check
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 21 Dec 2017 02:01:58 +0100] rev 3340
caches: factorise the cache warming check The old conditional was duplicated and hard to read. We factorise everything into the `utility` module.
Thu, 21 Dec 2017 00:06:07 +0100 stablerange: use repo-carried stablesortcache
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 21 Dec 2017 00:06:07 +0100] rev 3339
stablerange: use repo-carried stablesortcache That one is common to all and disk persisted
(0) -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 tip