On Sun, Jun 24, 2007 at 10:31:07PM +0100, Keith Packard wrote: > On Fri, 2007-06-22 at 15:36 +0400, Roman Kagan wrote: > > > The problem is the following: after that commit parsecvs tries to add > > objects to the git tree on its own via calls to libgit; however, in > > between it runs git-pack-objects. Thus objects move to pack files > > without libgit being aware of it; this results in 'ivalid object' > > errors. > > Sticking a call to reprepare_packed_git() after the pack creation fixes > this nicely. Ehm sort of... Except that I woudn't call that extern declaration nice. I'm now tracking down another problem which I didn't see before: parsecvs apparently doesn't close .git-cvs/log-XXX files and ends up exhausting the open file descriptor limit. I'll update when I have more info. > > Wouldn't it be better to teach parsecvs > > to speak git-fast-import language instead? > > Avoiding fork/exec is rather important for parsecvs perforamance. Avoiding _one_ fork/exec is certainly not. OTOH git-fast-import seems to be essentially the public API for the parsecvs kind of tasks. It may be wiser from the maintenance POV to use that instead of direct libgit calls (unless parsecvs is going to land in the git tree). I'll try to find the time and take a look at this somewhere next week. Roman. - 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
