fast-import doesn't recognise commits it generated?

Hi,

I'm trying to convert a PRCS repository into git using a custom
fast-import frontend. It's a very large repository, and I can't convert
it fast enough to stop users from committing to it while I convert it
(it takes 4+ days, PRCS is old and not that quick, and I've got over
7000 commits to migrate. I've been converting from a backup).

I've found that if I do an export up to a certain point, then attempt to
resume the export using the marks file generated by fast-import, it
complains saying (for example);

error: unable to find 185643da420354e861743f3056614f4dc78c0246
fatal: object not found: 185643da420354e861743f3056614f4dc78c0246

I tried this with version 1.5.6.5-3 (+lenny2~bpo40+1, on Debian Lenny),
and the offending hash and mark were in the marks file, quite a way
earlier than the point from which I attempted to resume the export.

I installed 1.7.1 from source and tried again and hit the same problem,
although this time it seems to have trampled the marks file in the
process - I had 47 entries instead of 10x that number before trying to
resume.

The only other information in the crash report is, "active_branches = 0
cur, 5 max". Not much to go on.

I'm wondering if there are conditions where fast-import will somehow
ignore a revision, or squash it into another revision, such that it
accepts and processes the command stream that I've generated but doesn't
generate a commit, despite it outputting a hash to the marks file?

Thanks and regards,

-- 
Rory Hunter