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).
(0) -3000 -1000 -300 -100 -14 +14 +100 +300 +1000 tip