[Monotone-devel] importing

[Tom Tromey]

Today I wanted to try importing libgcj again.  Last time I tried this,
monotone crashed.

I found something interesting.  "monotone scan" is really slow for
libgcj:

fleche. time monotone scan
real    4m0.775s
user    2m21.120s
sys     0m9.250s


Here is the same thing for a Classpath tree:

fleche. time monotone scan
real    0m6.076s
user    0m5.070s
sys     0m0.090s


These two trees are about the same size -- libgcj is 27M and Classpath
is 28M.  Both these commands were run after deleting my test database.
My machine is fairly quiescent, but I didn't take any special care.  I
did run each one a few times, and the above results are
representative.

So I suspect there is some pathological case triggered by one of the
libgcj files.

Graydon, I haven't collected the data you were interested in yet (size
of "monotone import" process, e.g.).  However I do know that I can
import classpath, but not libgcj.

It is really easy to reproduce this, if you have a little time.  I did
"cp -a" of the libjava tree from a recent gcc cvs checkout, removed
the ".#" and "~" files and CVS directories, and then scanned the
result.

Also, last time you asked about the ".out" files.  These are all
expected output files for the test suite.  They're all really small.
The biggest files in the tree:

fleche. find libjava -type f -ls | sort -nr -k 7 | head -10
6537562  628 -rw-r--r--   1 tromey   tromey     636043 Mar  6  2002 
libjava/gnu/gcj/convert/UnicodeData-3.0.0.txt
6537566  616 -rw-r--r--   1 tromey   tromey     625233 Oct 22  2001 
libjava/gnu/gcj/convert/Unicode_to_JIS.cc
9224842  440 -rw-r--r--   1 tromey   tromey     444208 Jul  1 16:47 
libjava/ChangeLog
9224849  340 -rw-r--r--   1 tromey   tromey     340511 Jan 21  2002 
libjava/ChangeLog-2001
9224869  272 -rwxr-xr-x   1 tromey   tromey     270394 Jun 30 17:48 
libjava/configure

600K is excessive, but monotone ought to be able to handle that
(actually the unicode file isn't in cvs -- I'll try again shortly
without it).  These may not be the biggest files in the gcc tree.

Tom