In main, marking as resolved

OK, so you say everything is fine.

Marking as testing, please reopen if I misunderstood.

The issue makarius found is not present in cvsps.py. If the user wants external
cvsps then he gets what he deserves^H^H^H^H^H^H^H asked for.

The problem I mentioned in msg6466 is hard to fix, and also quite unlikely to be
encountered, and I'm happy to leave this. No CVS log output parser will ever
cope with what a determined user could do to wreck it, for example using a log
message that contains the output of CVS log.

FYI, builtin cvsps is now used by default in crew.

What do we do about the current issue ?

When several commits make up one changeset, cvsps.py takes the date of the most
recent one, while cvsps-2.1 uses the oldest one. This was done deliberately to
help in identifying changesets on very large files, which might take more than
'fuzz' seconds to commit.

I have now checked with cvsps.py from the hg/crew repository.  Even when using
the same fuzz factor of 300, the result differs slightly: (1) changeset dates
often deviate by a couple of minutes, (2) the changeset boundaries are sometimes
a bit different (very rarely).

In general both results of the old cvsps-2.1 (after an adhoc patch) and your
cvsps.py look reasonable.  So I wonder if everything is actually OK, and the new
script merely uses different ways to interpret cvs dates.

Is this the proper place to continue this discussion of testing cvsps.py?

A wrapper is available in mercurial's hgext/convert directory. If you set the
PYTHONPATH correctly then you can run hgext/convert/cvsps, which will work in
much the same way as cvsps.c does.

You should then be able to diff the output of the two tools with little effort.

Yes, for the time being I am satisfied with the prospect to see cvsps.py in the
next official release -- at the moment it seems to in the development repository
only.

What I did in the (short!) time window of issueing the ticket and getting the
first response was to apply a quick-and-dirty fix to cvsps.c 2.1 and
successfully managed to convert 150 MB / 15 years of CVS history!  The result
can be seen here: http://isabelle.in.tum.de/isabelle-bin/mercurial.cgi

Now we are in the process of validating the result -- the original CVS is still
active.  The final conversion will probably happen within the next 6 months.

If it helps to stabilize the tool chain, I could try to compare the outcome of
cvsps.c vs. cvsps.py at some point, if you give me some hints how to do it.

makarius: does it solve your problem ?

cvsps.py seems to be working very well.

OK, the builtin cvsps.py is much more than the workaround that I was hoping for.

So the actual problem seems to be more in documentation or the default setup (of
Mercurial 1.0.1).

This is not a problem for builtin cvsps.

However, there is a potential issue if a commit log message has a line in it
which matches re_31 or re_32 (see hgext/convert/cvsps.py). That is, a line
containing exactly 28 dashes or 77 equal signs, and nothing else. I have come
across one of those in one of the (Free?)BSD CVS trees.

If that were to happen, then "cvs admin -m" might be a simpler workaround than
trying to make cvsps.py backtrack around this kind of problem.

When using hg convert on a CVS repository, there is a pending danger of loosing
log entries without further notice!  This is actually a problem of cvsps, which
ignores log entries reading like "foo: bar;" on the first line, because they are
mistaken as "revision meta data".

Included as a minimal example CVS where the effect shows up routinely -- many
empty log messages in the resulting hg.

Maybe there there is a workaround on the hg convert side.  At least one could
consider to add some words of warning to the hg convert documentation etc.