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.
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)