On Sun, 21 May 2006, Donnie Berkholz wrote: > > Fortunately the storms haven't been that bad down in Corvallis. cvsps > also worked fine for me, but git-cvsimport broke in the middle. Hmm. It's actually possible that it did that for me too - I had put the cvsimport in an xterm and forgotten about it, and just assumed that the power failure was what broke it. But maybe it had broken down before that happened - I just don't have any logs left ;) > Here's the last bits: > > [ snip snip ] > Commit ID 7a36de9c4c9b93337ed789ae2341cad3d0991c6d > Unknown: error Cannot allocate memory > Fetching profiles/package.mask v 1.992 > cat: write error: Broken pipe Hmm. I don't actually know perl, and my original "cvsimport" script was actually this funny C program that generated a shell script to do the import. That worked fine, and had no memory leaks, but it was a truly hacky thing of horrible beauty. Or rather, it _would_ have been that, if it had had any beauty to be horrible about. But at least I would have been able to debug it. But the perl one I can't parse any more. That said, the whole "Unknown:" printout seems to come from the subroutine "_line()", which just reads a line from the cvs server. Did you do a "top" at any time just before this all happened? It _sounds_ like it might actually be a memory leak on the CVS server side, and the problem may (or may not) be due to the optimization that keeps a single long-running CVS server instance for the whole process. I wouldn't be in the least surprised if that ends up triggering a slow leak in CVS itself, and then CVS runs out of memory. That would likely have been obvious in any "top" output just before the failure. Smurf, Martin, Dscho.. Any ideas? My old script just ran RCS directly on the files, and had no issues like that. I'll happily admit that my old script generator thing was horrible, but it was a lot easier to debug than the smarter perl script that uses a CVS server connection.. Linus - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html