view tests/test-evolve-issue6246.t @ 6935:954d7ea5cd67 stable tip

stack: when stack base is obsolete, pick any successor, even if at random

There are situations when s0 is obsolete and we also cannot pick just one
successor for it to use in stack. In such a case, let's pick the "latest"
successor from the first set.

We're assuming that obsutil.successorssets() returns data in the same order (it
should, since it makes sure to sort data internally). Keeping that in mind,
while the successor picked for s0 by this code is not based on any sort of
sophisticated logic, it should nonetheless be the same every time.

This patch is probably not going to completely break anything that was
previously working fine, because the previous behavior was to just abort with
an exception.

Failure to open evoext_stablerange_v2.sqlite shouldn't affect operations (issue6246)
https://bz.mercurial-scm.org/show_bug.cgi?id=6246

  $ . $TESTDIR/testlib/common.sh

  $ cat << EOF >> $HGRCPATH
  > [extensions]
  > evolve =
  > EOF

  $ hg init issue6246
  $ cd issue6246
  $ hg debugbuilddag '.+6'

making a cache file that sqlite cannot open shouldn't break stablerange cache

  $ touch .hg/cache/evoext_stablerange_v2.sqlite
  $ chmod 0000 .hg/cache/evoext_stablerange_v2.sqlite

  $ hg debug::evo-ext-stable-range --method default --verify --subranges --rev 1 --debug
  stable-range cache: unable to load, regenerating
  66f7d451a68b-0 (1, 2, 2) [complete] - 1ea73414a91b-0 (0, 1, 1), 66f7d451a68b-1 (1, 2, 1)
  1ea73414a91b-0 (0, 1, 1) [leaf] - 
  66f7d451a68b-1 (1, 2, 1) [leaf] - 

  $ hg debugobshashrange --rev tip --debug
  stable-range cache: unable to load, regenerating
           rev         node        index         size        depth      obshash
  obshashrange cache: unable to load, regenerating
             6 f69452c5b1af            0            7            7 000000000000

  $ cd ..