Alex Bennee wrote: > If this is using the inbuilt cvsps and perl then it will likely choke > on very large CVS repos. For some CVS tree's I've had to resort to a > hacked up version of parsecvs to get a conversion running. I gather cvsps has to read the whole history to be able to interpret the latest commits, is that right? In which case a long history is going to generate long waits on each import. And possibly eat lots of memory too. I do actually have a larger CVS tree to test it on than I have been using (it's about a decade's worth of changes on a production website) but I didn't want to set myself up for a fall by tackling it. For now, my aim has been to keep CVS "out of the living room" whilst I work on the small CVS module that concerns me. Meanwhile, I'm hoping to convince the powers that be that CVS needs to be replaced, preferably with Git, before I get asked to work on something larger. However, if you can test it on your repository, and with your patched version of parsecvs, that would be a good thing. Especially if it works. Thanks, N -- To unsubscribe from this list: 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