Oh, and a really weird observation, that maybe someone out there can validate — or maybe someone can prove to me that I’m smoking crack: banging randomly on your keyboard makes subversion work better.
So here’s the story. I kept trying to run nightly builds of Sugar in tinderbox mode, and jhbuild kept hanging up on libxml2. Basically, svn.gnome.org would time out. I sent a note to Behdad saying “is svn.gnome.org slow for anyone else?” And he said no, not really, and I said, huh. So I ran the build again in the background while I worked, and lo and behold, it pulled libxml2 with no problems. Excellent. I wandered off to lunch. I came back, and jhbuild was now hung on subversion checkout of something else.
After a while, it became clear that when I was running a big svn checkout while I was doing other stuff, it would go very well — but if I did a big svn checkout unattended, it would hang and eventually timeout. WTF?
So then I googled for “svn slowness” and “svn timeout” and “svn you suck” and “svn why must you torture me,” and after lots and lots and LOTS of searching, I saw a similar complaint from someone who had similar problems checking stuff into subversion. He blamed it on svn’s reliance on /dev/random calls instead of using the less-random-but-faster /dev/urandom.
Now, I’m just an unfrozen caveman community guy. Your scary talking boxes frighten me. I don’t understand your mechanical thunder-chariots, and I don’t understand why svn would need to use either /dev/random or /dev/urandom. But I do know this: when /dev/random needs more entropy, I will bang on my keyboard like a million monkeys, and by God, my svn checkouts will work.
Which brings me to my real question: is there a good reason for not compiling svn to use /dev/urandom by default? Does anyone know?