built-in cvsps now in crew, with a testcase for this.

This works just fine with built-in cvsps.py.
Built-in cvsps is still not in the crew, see the mailing list for patches:
http://marc.info/?l=mercurial-devel&m=120906303303042&w=2

$ hg convert project 
assuming destination project-hg
initializing destination project-hg repository
using builtin cvsps
collecting CVS rlog
7 log entries
creating changesets
5 changeset entries
connecting to /tmp/cvsroot
scanning source...
sorting...
converting...
4 Initial revision
3 init
2 mod a
1 mod b
0 mod a again
updating tags

$ hg log
changeset:   5:bba117f928f8
tag:         tip
parent:      0:4208ca31a51b
user:        convert-repo
date:        Fri May 30 07:41:14 2008 +0000
summary:     update tags

changeset:   4:6ac90091bc49
branch:      BRANCH
user:        fk
date:        Fri May 30 08:41:00 2008 +0100
summary:     mod a again

changeset:   3:67c3ac00bb44
branch:      BRANCH
user:        fk
date:        Fri May 30 08:40:53 2008 +0100
summary:     mod b

changeset:   2:ad871da884dc
branch:      BRANCH
user:        fk
date:        Fri May 30 08:40:47 2008 +0100
summary:     mod a

changeset:   1:d50eef4f5bec
branch:      v0
tag:         r0
user:        fk
date:        Fri May 30 08:40:16 2008 +0100
summary:     init

changeset:   0:4208ca31a51b
user:        fk
date:        Fri May 30 08:40:16 2008 +0100
summary:     Initial revision

Here is a way to reproduce the bug:

$ cd /tmp/
$ export CVSROOT=/tmp/cvsroot
$ cvs init

Create a new project

$ mkdir project
$ cd project
$ echo "1" > a > b
$ cvs import -m "init" project v0 r0
$ cd ..
$ cvs co project
$ cd project

Branch the project

$ cvs tag -b BRANCH
$ cvs up -r BRANCH

Modify file a, then b, then a 

$ echo "2" > a
$ cvs ci -m "mod a"

$ echo "2" > b
$ cvs ci -m "mod b"

$ echo "3" > a
$ cvs ci -m "mod a again"

Convert

$ cd ..
$ hg convert project

Check the result

$ cd project-hg
$ hg log
assuming destination project-hg
initializing destination project-hg repository
connecting to /tmp/cvsroot
scanning source...
sorting...
converting...
3 Initial revision
2 init
1 mod a
0 mod a again
updating tags


Note that 'mod b' is not present!
'hg log' confirms it:

$ hg log
changeset:   4:e3a42c644195
tag:         tip
parent:      0:f81cf7d4abef
user:        convert-repo
date:        Tue May 27 08:28:35 2008 +0000
summary:     update tags

changeset:   3:5c3706d58761
branch:      BRANCH
user:        fb
date:        Mon May 26 22:29:51 2008 -0400
summary:     mod a again

changeset:   2:d5d5cb5719a2
branch:      BRANCH
user:        fb
date:        Mon May 26 22:28:32 2008 -0400
summary:     mod a

changeset:   1:a2bb6a29d087
branch:      t0
tag:         v0
user:        fb
date:        Mon May 26 22:26:47 2008 -0400
summary:     init

changeset:   0:f81cf7d4abef
user:        fb
date:        Mon May 26 22:26:47 2008 -0400
summary:     Initial revision



The problem comes from the way the parents of revisions are handled in 
the function convert_csv._parse() (hgext/convert/csv.py):


98 elif state == 2: # members
99 if l == "\n": # start of next entry
100 state = 0
101 p = [self.parent[id]]
102 if id == "1":
103 p = []
104 if branch == "HEAD":
105 branch = ""
106 if branch:
107 latest = None
108 # the last changeset that contains a base
109 # file is our parent
110 for r in oldrevs:
111 latest = max(filerevids.get(r, None), latest)
112 if latest:
113 p = [latest]
114
115 # add current commit to set
116 c = commit(author=author, date=date, parents=p,
117 desc=log, branch=branch)
118 

The parent of the last commit of the file 'a' is here detected as being the 
first commit of 'a'. 
When the heads are walked in converter.walktree, 
the changeset "mod b" is never seen because it's not head and 
no changeset refers to it (as a parent).