Ticket #26270 (closed: self-service)
svn checkout of text file fails while slightly modified version has no issue.
|Reported by:||lperkins2||Owned by:||ctsai|
When attempting an svn checkout of revision 196 of UGM Inventory System (https://sourceforge.net/projects/ugminventorysys/),
~/svn $ svn co https://svn.code.sf.net/p/ugminventorysys/code/trunk/Client Client -r 196 Authentication realm: <https://svn.code.sf.net:443> SourceForge User Password for 'lperkins2': A Client/Common.py A Client/HelpScreen.py A Client/Version.py.in A Client/MovementScreen.py A Client/install.txt A Client/InventoryScreen.py A Client/PartnersScreen.py A Client/Connection.py A Client/setup.py A Client/DummySettings.js svn: REPORT of '/p/ugminventorysys/code/!svn/vcc/default': Could not read chunk size: Secure connection truncated (https://svn.code.sf.net)
Using the svn protocol instead of https (svn co svn://svn.code.sf.net/p/ugminventorysys/code/trunk/Client Client -r 196
) produces a different error on the same file.
svn: Decompression of svndiff data failed
The file causing the problem is ProductsScreen.py, a checkout of each other file by name, one at a time works. Except for ProductsScreen.py, which fails.
Looking about online, the https error is often caused by a connection timeout or firewall issue, however at 16952 bytes, I doubt it is timing out.
In regards to the svn protocol error, according to this, it may have had something to do with a problem when the file was committed, so I rolled the version back to the last changed revision, and then committed the old version. It worked. However, when I again tried to commit my changes, it once again broke, same behaviour as before. At that point, I tried removing the broken file and readding it, instead of updating from the previous revision. Also broke it. And then I tried adding it to a different point on the svn tree (/web%20interface instead of /Client) which also broke. I then removed the file from it again, and re-added it, this time after making a trivial change to one of the comment lines, it worked without issue. I added the bad file to my own svn server for testing, and it worked without problem, (svnserve, version 1.6.17 (r1128011))
The change is the comment line in the file is trivial, so I am not worried about the error at the moment, but I am including a copy of the file that reliably causes the problem so maybe we can figure out the root of the issue.