[cvsnt] Windows resource files getting corrupted.
Sumanjit Kaur Brar
SBrar at quark.com
Fri May 2 08:08:40 BST 2008
I have noticed one thing, The resource files which shows the duplicated content have changing kopt type between "u" and "kv" in their ,v files. Interchanging between kopt types actually helped. I have no idea how it worked.
Ext : 9878
This e-mail transmission and any documents, files, or previous e-mail messages appended or attached to it, may contain information that is confidential or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that you must not read this transmission and that any disclosure, copying, printing, distribution, or use of the information contained or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by telephone (+91.172.2299878) or return e-mail message (< mailto:sbrar at quark.com>) and delete the original transmission, its attachments, and any copies without reading or saving in any manner. Thank you
From: Arthur Barrett [mailto:arthur.barrett at march-hare.com]
Sent: Friday, May 02, 2008 12:01 PM
To: cvsnt at cvsnt.org
Subject: RE: [cvsnt] Windows resource files getting corrupted.
Just some disclosure to the newsgroup.
Chuck did send through a test set on this which I've just finished
looking at. We haven't heard from Suman since the initial report - no
additional info - nothing.
> > Chuck Kirschman wrote:
> >> One case where I've seen this is if the file being
> committed has a mix
> >> of \r and \r\n characters.
> > That can't happen at all on cvsnt - it has safeguards on
> both the client
> > and server to avoid problems caused by mixed line endings.
> The issue happened on 18.104.22.1680 server with a 22.214.171.1242 client.
> Perhaps I misinterpreted the mechanism, but the file is certainly
> trashed, and correcting the line endings in the XML file before
> committing it did stop the problem from happening. I think I
> still have
> a copy of the corrupt ,v file if you're interested. I don't have the
> original XML though.
The issue that Chuck has described does NOT corrupt past revisions,
however future revisions are altered unexpectedly: this is a known bug
since 2006-11-17 fixed on the commercial side on 2006-11-18 and made it
to production releases on 2007-03-16:
The details of my testing of Chuck's test set to prove past revisions
are unaffected is here:
I've added the 4729 patch to the 2.5.04 branch now so the next 2.5.04 RC
will have the fix . Notes:
1. past revisions will still exhibit the 'problem', but if you fix a
file and commit a 'fixed' version then all will be well for new
2. I'm not testing 2.5.04 - that's up to the community to do, so if I've
missed something important in the merge then someone will have to test
and report it when then next RC is out.
Since 2.5.04 is a feature release I was not intending trying to backport
any of the 2.5.03 fixes to it - it'd delay the release even further.
2.5.04.2382 as proven to be an extremely stable FOSS release. We've
found FOSS users generally use different features to our commercial
support users, for whom the 100's of fixes in 2.5.03 are important. All
the fixes are in the repo so if anyone wants to help out in porting them
then that's a good thing.
The only other 'commercial' bug that anyone has ever reporting in the
FOSS version is the 'out of memory' with >500Mb revisions - which is
actually a bug in the MS C runtime though we found a workaround for our
commercial users - there is no way I've got time to port that to 2.5.04,
and 500Mb revisions just isn't a common FOSS requirement.
There is still no way that any of this explains the original bug report
- unless that was a unicode .rc file?
I've BCC'd Chuck Kirschman and Suman Brar.
More information about the cvsnt