view tests/test-merge5.t @ 17970:0b03454abae7

ancestor: faster algorithm for difference of ancestor sets One of the major reasons rebase is slow in large repositories is the computation of the detach set: the set of ancestors of the changesets to rebase not in the destination parent. This is currently done via a revset that does two walks all the way to the root of the DAG. Instead of doing that, to find ancestors of a set <revs> not in another set <common> we walk up the tree in reverse revision number order, maintaining sets of nodes visited from <revs>, <common> or both. For the common case where the sets are close both topologically and in revision number (relative to repository size), this has been found to speed up rebase by around 15-20%. When the nodes are farther apart and the DAG is highly branching, it is harder to say which would win. Here's how long computing the detach set takes in a linear repository with over 400000 changesets, rebasing near tip: Rebasing across 4 changesets Revset method: 2.2s New algorithm: 0.00015s Rebasing across 250 changesets Revset method: 2.2s New algorithm: 0.00069s Rebasing across 10000 changesets Revset method: 2.4s New algorithm: 0.019s
author Siddharth Agarwal <sid0@fb.com>
date Mon, 26 Nov 2012 11:46:51 -0800
parents 6da47b655d97
children 76df01e56e7f
line wrap: on
line source

  $ 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