view tests/test-merge5.t @ 18040:fe8caf28d580

strip: make query to get new bookmark target cheaper

The current query to get the new bookmark target for stripped revisions
involves multiple walks up the DAG, and is really expensive, taking over 2.5
seconds on a repository with over 400,000 changesets even if just one
changeset is being stripped.

A slightly simplified version of the current query is

max(heads(::<tostrip> - <tostrip>))

We make two observations here.

1. For any set s, max(heads(s)) == max(s). That is because revision numbers
   define a topological order, so that the element with the highest revision
   number in s will not have any children in s.

2. For any set s, max(::s - s) == max(parents(s) - s). In other words, the
   ancestor of s with the highest revision number not in s is a parent of one
   of the revs in s. Why? Because if it were an ancestor but not a parent of s,
   it would have a descendant that would be a parent of s. This descendant
   would have a higher revision number, leading to a contradiction.

Combining these two observations, we rewrite the revset query as

max(parents(<tostrip>) - <tostrip>)

The time complexity is now linear in the number of changesets being stripped.
For the above repository, the query now takes 0.1 seconds when one changeset
is stripped. This speeds up operations that use repair.strip, like the rebase
and strip commands.

  $ hg init
  $ echo This is file a1 > a
  $ echo This is file b1 > b
  $ hg add a b
  $ hg commit -m "commit #0"
  $ echo This is file b22 > b
  $ hg commit -m "comment #1"
  $ hg update 0
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ rm b
  $ hg commit -A -m "comment #2"
  removing b
  created new head
  $ hg update 1
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ hg update
  abort: crosses branches (merge branches or update --check to force update)
  [255]
  $ rm b
  $ hg update -c
  abort: uncommitted local changes
  [255]
  $ hg revert b
  $ hg update -c
  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
  $ mv a c

In theory, we shouldn't need the "-y" below, but it prevents this test
from hanging when "hg update" erroneously prompts the user for "keep
or delete".

Should abort:

  $ hg update -y 1
  abort: crosses branches (merge branches or use --clean to discard changes)
  [255]
  $ mv c a

Should succeed:

  $ hg update -y 1
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved