Andrew - it wouldn't be the first time I've made something more complicated than it needs to be, but here's why I think there may be more going on than just a botched import -
"release-2003-11-18__branch" was branched off tammy's main development tree, but the revision numbers there look very much like it was branched from the vendor branch rather than from the trunk (all the CVS documentation I've ever seen says that all revision numbers on the trunk have a single period and gain 2 periods for each branching away from the trunk). 1.1.1 is the default vendor branch, so it would be normal for a file unchanged since import to be on the trunk with revision "1.1.1.1" as you say, but "1.1.1.1.2.1" is a revision on a branch off the vendor branch. If "release-2003-11-18__branch" was branched off the trunk then the revision numbers there would be of the form "1.x.2.y"
If this is the case then the development tree *is* the vendor branch and fixing it isn't as simple as just redoing the import... This situation isn't hard to imagine - if the original working copy was checked out with the release tag of the initial import (an easy mistake to make) then that working copy will be on the vendor branch. Since this was the first import since the initial one everything would have appeared to be working fine in the interim.
Like I said it looks to me like development may be on the wrong branch, which would cause problems with imports, but I'd want to see output from something like CvsGraph before speculating any further. I'll shut up now...
