Mercurial > hgsubversion
view tests/fixtures/executebit.sh @ 787:4bbc6bf947f5 1.2.1
replay: fetch full revision at most once per run (issue252)
Before this change, hgsubversion was fetching full revisions from the first
revision the project was created to the first revision containing converted
data. Unfortunately, some projects exhibits such spans longer than 500
revisions, during which hgsubversion was uselessly scanning the whole tree. The
fix is not technically perfect, we could record somewhere that while no data
was converted we scanned the project already, instead of scanning once at every
hgsubversion run until a revision is converted. But it should be good enough
unless someone runs hgsubversion once for every target revision.
One repository exhibiting this behaviour:
svn://svn.zankasoftware.com/zanka
| author | Patrick Mezard <pmezard@gmail.com> |
|---|---|
| date | Sun, 13 Feb 2011 20:10:52 +0100 |
| parents | c35f59aa200e |
| children |
line wrap: on
line source
#!/bin/sh # # Generate executebit.svndump # mkdir temp cd temp mkdir project-orig cd project-orig mkdir trunk cd .. svnadmin create testrepo svnurl=file://`pwd`/testrepo svn import project-orig $svnurl -m "init project" svn co $svnurl project cd project/trunk echo text > text1 echo text > text2 touch empty1 touch empty2 python -c "file('binary1', 'wb').write('a\x00b')" python -c "file('binary2', 'wb').write('a\x00b')" svn add text1 text2 binary1 binary2 empty1 empty2 svn propset svn:mime-type application/octet-stream binary1 binary2 svn propset svn:executable yes binary1 text1 empty1 svn ci -m init # switch exec properties svn propdel svn:executable binary1 text1 empty1 svn propset svn:executable yes binary2 text2 empty2 svn ci -m changeexec cd ../.. svnadmin dump testrepo > ../executebit.svndump