@lloyd: could you provide the same patch in export format, so I have your
username/email and a log entry?

This patch looks pretty benign, and I have no problem with it going in.

There is a second case where lookahead is required and the attached diff
fixes it. Should a separate issue be opened for the case where a log history
has been entered as a log message? That's quite hostile input and the fix
for that is quite different. I guess that the revision numbers could be
tracked and entries thay are not in sequence are the hostile input. Also,
the CVS head revision gives some limits on what revision numbers are possible.

Also, I've seen cases where a single line lookahead will not do the job. 
Some people paste multiple full revision logs (including the 'revision'
line) as "documentation" for their commit (like a merge of multiple changes
from a different cvs branch).  It happens unfortunately.  Without using cvs
or rcs to grab the log entry for a revision, it's hard in some cases in the
real world to tell where a cvs log entry ends.

I am running 1.3.1 which has that change.  So, no, it wasn't fixed.  The
exception happens in state 5 in createlog(), whereas the lookahead added in
the changeset you mentioned does not happen until state 7.

p.s. 'cvs admin' is out since this is a read-only cvs repo from a third
party (and incremental converts are needed, so a 1-time hack is not a good
option).

Was this not fixed with 9811cc670c51af8dd369f7925f6f4401a976d747?

cvsps: cvs log loop uses lookahead to avoid misleading text

Changes cvsps.py's cvs log reader to use a one-line lookahead, so
that possibly misleading log messages can be disambiguated.  In
particular I have past committers who used cvs log's 28-character
row of hyphens within commit messages; this throws cvsps and disrupts
conversion.  The only alternative in this case is to edit the cvs
,v file by hand, which bloodies mercurial's "don't change history"
principle.

Or use cvs admin -m.

hgext/convert/cvs.py can be confused by certain log entries.

The most recent example I ran into was a log entry that had 28 dashes in the
middle of the log.  This confused cvs.py which expected a revision line to
be next.

 .
 .
----------------------------
revision 1.6.10.3
date: 2009/05/22 22:07:49;  author: foo;  state: Exp;  lines: +9 -1
branches:  1.6.10.3.4;
merge from head:
   ... blah blah
----------------------------
date: 2009/04/19 15:48:16;  author: mtm;  state: Exp;  lines: +4 -2
  ... blah blah some change on head
----------------------------
 .
 .

This is only one cvs log entry, but cvs.py gets confused and thinks
otherwise, throwing this error:

AssertionError: expected revision number

Possible solutions?
 - don't die on unexpected log parsing issues, but rather assume it was not
a new cvs log entry
 - better: use cvs to grab the log entry instead of trying to guess where
log entries begin and end in cvs.py (e.g., 'cvs log -N -r1.6.10.3' in the
above example would output the log lines which we can record and skip over
in cvs.py)