[cvsnt] Re: unexpected '\x0' reading revision number in RCS file

Bo Berglund bo.berglund at telia.com
Sat Jun 3 23:45:13 BST 2006


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.


On Sat, 3 Jun 2006 17:47:37 -0400, "Jesse" <cvs at gamesthatwork.com>
wrote:

>As for upgrading the server version, approximately 1/10 comments on this 
>thread seem to be about how the latest version corrupted binary files.  So 
>upgrading to that version seems an unnecessary risky, since 1/2 of are files 
>are binary.

I can count to 8 messages in this thread *including* the one you have
just posted.
1/10 * 7 = 0 or 1 depending how you do your integer math.
The one talking about binary corruption is yourself and there is
nothing there regarding the *latest* CVSNT version...

There were a few occurrencies of corruption of binary files in the
past, all suggested that CVSNT somehow got confused about the file
type (binary or text). The use cases were a bit strange too, so it is
not a commonplace thing:

Binary corruption bug in builds 1910-1969 at least:
- Add a binary file, it gets rev 1.1
- cvs remove and commit it
- check out revision 1.1 of that same file and it is LF-corrupted!
Fixed in build 1997 (or earlier)

Import corruption in build 2127 with client 2.0.51d
For the combination of server/client above import of a binary file
leads to line ending corruption. Changing the *client* to 2127 fixes
this problem. 2.0.51d was not a supported release.

Furthermore, the corruption you have described (at least how I have
understood it) was caused by a process made by yourself directly
manipulating the RCS files in the repository, right?
So how can CVSNT come into that?


HTH

/Bo
(Bo Berglund, developer in Sweden)



More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook