view tests/svn/svndump-startrev.sh @ 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

#!/bin/sh
#
# Use this script to generate startrev.svndump
#

mkdir temp
cd temp

mkdir project-orig
cd project-orig
mkdir trunk
mkdir branches
mkdir tags
cd ..

svnadmin create svn-repo
svnurl=file://`pwd`/svn-repo
svn import project-orig $svnurl -m "init projA"

svn co $svnurl project
cd project
echo a > trunk/a
echo b > trunk/b
svn add trunk/a trunk/b
svn ci -m createab
svn rm trunk/b
svn ci -m removeb
svn up
echo a >> trunk/a
svn ci -m changeaa

# Branch
svn up
svn copy trunk branches/branch1
echo a >> branches/branch1/a
svn ci -m "branch, changeaaa"

echo a >> branches/branch1/a
echo c > branches/branch1/c
svn add branches/branch1/c
svn ci -m "addc,changeaaaa"
svn up
cd ..

svnadmin dump svn-repo > ../startrev.svndump