I agree that the original poster is in version-control hell, but I have a different approach to working it out.

• In the terms CVS uses, your local files are a sandbox. The CVS tool makes ./CVS/ metadata directories in each actual directory in your sandbox. The metadata in these files is specific to the repository from which you collected this sandbox.
• Therefore, all CVS sandboxes are inextricably associated with a given repository. Don't muck with that, or you'll go crazy. Any tweak which doesn't work flawlessly can really mess up each repository you're trying to touch. And any tweak you're performing which is CVS-specific will just tie you into the aging CVS solution instead of alternatives like Subversion, Perforce, etc.
• Instead of hacking CVS metadata, work with TWO sandboxes. Sandbox A for Repository A. Sandbox B for Repository B. When you sync up your Sandbox A and find a bundle of changes, merge it over into your Sandbox B as a unit, test the Sandbox B for functionality, and if they pass, then commit Sandbox B.
• There are tools which help you deal with merging two sandboxes. For the Windows platform, I would recommend Beyond Compare by Beyond software. Very visual, very easy to compare two whole sandboxes and pick-and-choose what needs to get merged where. For the Unix platform, you should get familiar with diff -ruN and various post-processors like xdiff which can help you visualize and manage the differences.

In short, don't try to multi-purpose one sandbox. It'll just lead to major headaches.