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

[Jesse]

Sorry, by 1/10 of this thread, I actually meant 1/10 of the support.cvsnt 
message board.  It was hyperbole, and apparently outdated at that.  But it 
seems that there are bugs in build 2260 (re: [cvsnt] Re: Can no longer 
commit binary files (w/delta) after
2260update (audit-issue?) ) a thread that you actually commented on.

When I think of binary files, I'm thinking specifically of large art files 
that require binary deltas.

But my statement was actually in respose to Glen's comment that I should 
upgrade.  I am wary about changing anything if people are having problems 
( hardly an noble sentiment, I know).

The bug was caused myself.  I forgot to decriment the bytes my converter had 
read when it hit the EOF, causing the zero'd out buffer to be one character 
too long... a null character was thus added to the end.

Took a while to find.

"Bo Berglund" <bo.berglund at telia.com> wrote in message 
news:0a24825s7rhq228g25bfjqpcjnbr5ra8i5 at 4ax.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)