Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
I just reverified that the bug exists using version 2.5.01 (Travis) Build 1949 on the both sever and the client. The server is a Windows 2K system and the client is a Windows XP system. Here is exactly what I did. I created a text file with DOS lined endings (i.e. 0D0A) I verified via hex editor that 0D0A was there for every new line. I added the file as a binary file with the command. cvs add -kB -m" " test3.txt cvs ci -m" " test3.txt I deleted the file from my sandbox and rechecked out the file with the command. cvs up -A -C test3.txt I verified that the file has all the 0D0A sequencies I expect. I deleted the file from my sandbox then removed it from the CVS module via the command cvs remove test3.txt cvs ci -m" " test3.txt I then checked out rev 1.1 of the file. cvs up -r 1.1 test3.txt I used hex a editor to check for 0D0A line endings and found that all 0D0A sequences are changed to just 0A. Matt S. "Tony Hoyle" <tmh at nodomain.org> wrote in message news:d627d5$nu6$1 at paris.nodomain.org... > Bo Berglund wrote: > > I can confirm this behaviour: > > > > 1) I am running 2.5.01.1949 as both server and client > > 2) I copied in a binary file to an existing sandbox > > 3) I added it binary and committed, got revision 1.1 > > 4) Then I cvs removed the file and committed > > 5) Then in another empty folder I checked out revision 1.1 > > The metadata still say it's a binary file. > > I've just done exactly this and it worked correctly. > > Is there something else you're doing that could be affecting it? > > Tony