Why do my text files suddenly have an additional at the end of each line?

The reason for this is CVS committing DOS-style text files (i.e. with  line endings) as UNIX-style text files (with  line endings). There are many ways how this can happen, so first some general rules:

You should only access a repository using CVSNT, either directly from the command line or through wrapper applications like WinCVS or TortoiseCVS that use CVSNT internally.
It's highly recommended not to access your sandbox (that was checked out with TortoiseCVS, CVSNT or WinCVS) using other CVS clients, especially not with UNIX-style CVS clients (like Linux's or Cygwin's) because of line ending incompatibilities.
It's highly recommended to use TortoiseCVS only for sandboxes that were checked out with TortoiseCVS, WinCVS or CVSNT - for example, files checked out with the Eclipse CVS client may be treated as UNIX files by TortoiseCVS, which causes the additional  .
Furthermore, you have to be careful when you've checked out a module using UNIX line endings. You must not edit those files with a Windows text editor that overwrites the UNIX line endings with DOS line endings, or else you'll eventually get that additional  at the end of each line.
If the above satisfies you, stop here. If you'd like to know the details, continue reading.

The technical details
Okay, I've warned you ;)

In Windows, text file line endings consist of the byte sequence  ($0D$0A), while UNIX line endings only consist of a single  ($0A). Loading a UNIX-style text file on Windows (or vice versa) may cause errors. Therefore, to be able to share text files across platforms, line endings have to be converted.

CVS internally stores line endings in UNIX style. So when committing a Windows-style text file to CVS,  has to be converted to before storing it on the CVS server. The opposite when updating: When a text file is downloaded from the CVS server,  has to be converted to  before writing it to a sandbox on a Windows system. CVSNT by default does all those conversions automatically.

But other CVS clients don't do those conversions. Now, assume you commit a Windows-style text file using a non-CVSNT client. As this CVS client won't convert the line endings before uploading the file to CVS, the server repository will contain  line endings instead of  . This leads to the following problems:

If you check out the file on UNIX (where no conversion is performed), the line endings will be  and not  , which is wrong.
If you check out the file on Windows using CVSNT, it will convert each  to a  to set the correct line endings for Windows. Unfortunately, the server copy of the file already had a  before the  . As a result, the local line endings will be  - the file is totally screwed up.
BTW: The above applies only to text files - binary files (keyword expansion -kb) are never converted.

UNIX line endings on Windows
As you might know, TortoiseCVS has the option to check out modules using UNIX line endings. When the user modifies and commits a file in a UNIX sandbox, TortoiseCVS assumes that this file has UNIX line endings, and passes a "--lf" to CVSNT on the commandline, which instructs CVSNT to treat the file as one with UNIX line endings.

To detect whether a module was checked out with UNIX line endings, TortoiseCVS looks at the CVS administrative files in the CVS subdirectory: If the line endings for those files are in UNIX style, a UNIX sandbox is assumed. Unfortunately, there are some CVS clients (e.g. Eclipse) which create those files without a single line ending, so TortoiseCVS cannot detect them as UNIX sandbox. There's a preference setting that instructs TortoiseCVS whether to default to DOS or UNIX in such cases.