view tests/test-issue842.t @ 18986:2f7186400a07

ancestor: a new algorithm that is faster for nodes near tip

Instead of walking all the way to the root of the DAG, we generate
a set of candidate GCA revs, then figure out which ones will win
the race to the root (usually without needing to traverse all the
way to the root).

In the common case of nodes that are close to each other in both
revision number and topology, this is usually a big win: it makes
"hg --time debugancestors" up to 9 times faster than the more general
ancestor function when measured on heads of the linux-2.6 hg repo.

Victory is not assured, however. The older function can still win
by a large margin if one node is much closer to the root than the
other, or by a much smaller amount if one is an ancestor of the
other.

For now, we've also got a small paranoid harness function that calls
both ancestor functions on every input and ensures that they give
equivalent answers.

Even without the checker function, the old ancestor function needs
to stay alive for the time being, as its generality is used by
context.filectx.merge.

http://mercurial.selenic.com/bts/issue842

  $ hg init
  $ echo foo > a
  $ hg ci -Ama
  adding a

  $ hg up -r0000
  0 files updated, 0 files merged, 1 files removed, 0 files unresolved

  $ echo bar > a

Should issue new head warning:

  $ hg ci -Amb
  adding a
  created new head

  $ hg up -r0000
  0 files updated, 0 files merged, 1 files removed, 0 files unresolved

  $ echo stuffy > a

Should not issue new head warning:

  $ hg ci -q -Amc

  $ hg up -r0000
  0 files updated, 0 files merged, 1 files removed, 0 files unresolved

  $ echo crap > a
  $ hg branch testing
  marked working directory as branch testing
  (branches are permanent and global, did you want a bookmark?)

Should not issue warning:

  $ hg ci -q -Amd