Need a way to ignore CVS "cvs [update aborted]: invalid change text in ..."

[PerMildner]

Apparently our CVS repository is corrupted. It would be nice to be able to ignore broken versions somehow.

I do not much care if some old versions are corrupted in git, the old files are just of historical interest. The important thing is to have a valid file representing the most recent version.

It will not be possible for us to recover (from backup) or attempt to repair broken RCS files.

It is possible that, in our case, the broken files are all in Attic, so a way to ignore Attic files may help.

~/crap/crap-clone --force ~/cvs_src ...
...
1998-01-09 12:04:34 PST COMMITcvs: cvs [update aborted]: invalid change text in .../Win32/Attic/sp3w32rt.wse,v
Did not get Update line: 'error  '
spdev@ubuntu:~/git_src3$ fatal: stream ends early
fast-import: dumping crash report to .git/fast_import_crash_83447

[rcls]

Ugh. You are having fun. I am not sure I will find time to work on this, but you may be able to work around the problem without changing crap-clone:

The quickest way to ignore the attic files may well be to make a copy of your repo, delete all the Attic/*,v files and run crap-clone on the result.
[Please understand the consequences of doing this - a file is in the attic if it has been deleted (or never existed) on the trunk. It may still be present on a branch.]

Slightly more work would be to attempt to use 'rcs -o' (or 'cvs admin -o') to remove the broken revisions from the ',v' files. Again, I recommend doing that on a copy of the cvs repo, at least until you understand the consequences.

If you feel like attempting the crap-clone change yourself, do something like the following: In crap-clone.c, about line 115, function read_version(), don't call fatal() when the error is detected. Instead, close and reopen the CVS connection, and return.

Then at the end of grab_version() about line 241 of crap-clone.c, if we have failed to retrieve the version, then instead of calling fatal(), set version->mark = parent->version->mark. (The latter should be filled in by then).

NB. It is very likely completely essential to close and re-open the CVS connection after an error, even if it looks like both sides have recovered. CVS maintains working state on the server side, and it is likely that state is invalid after an error.

[PerMildner]

Thanks. I just removed the offending ',v' files (there were two, both in Attic) so now it looks as if our CVS repo, with history from 1994, can be migrated to git. Nice!

[sylvandb]

I see this is still a problem :(

So far this tool has been awesome, I'm going to try and fix the ',v' and see... otherwise I may work on fixing crap-clone!

Edit: I was able to "fix" my ',v' file (identified the bad version using cvs up -p -r# then found line numbers part way thru that file were off by 1, causing the last change for that version to extend past the end of the file).

Crap-clone is by far the best cvs conversion I've found!