I have recovered SVN repository from crashed PC and now I can checkout files from few directories but in one place during checkout it says:
Error: REPORT of '/svn/RepTest/!svn/vcc/default': Could not read chunk size:
Secure connection truncated (https://mypc:8443)
Could anyone help me, how to fix that repository? Thanks!
I've just had the same error when trying to update a checkout to the latest revision. Some fiddling about revealed that it was one particular file causing the issue. For example:
root
- A
- AFileInFolderA.h
- AnotherFileInFolderA.h
- B
- AFileInFolderB.h
- C
- AFileInFolderC.h
With the repo structure above, AFileInFolderA.h was the problem file. I came to this conclusion because I could do and svn update in folders B and C but not on the root or folder A. Drilling down further, I could update AnotherFileInFolderA.h but not the problem one.
Anyway, with that information in hand I copied my working copy changes from folder A, then (using Tortoise SVN) did a selective Update To Revision on the root folder, excluding folder A from my checkout. I then did the reverse, re-adding the folder to the checkout. Finally I added my local changes back in and committed to the repo. All is now working fine.
When checking out I got the same error. The problem was indeed with specific revisions, so I did a workaround. It seemed that the revisions that raised the error had a long path. Another look on the specific revisions got me to think it might not need to be under source control. These files were generated automatically upon every build. I just kept another copy of the entire directory in a 'Deprecated' folder, and deleted the problematic files/folders. After the deletion, checkout was OK.
I had the same error recently:
REPORT of '/svn/.../!svn/vcc/default': Could not read chunk size: Secure connection truncated.
We are using Tortoise SVN and I was the only one in the team that had the issue. Since the problem didn't prevent me from committing my changes, I did just that. Next I removed the folder with the project from my hard drive. Then I created it again and made an "SVN checkout".
This is what fixed it for me.
Yet another answer by someone with the same problem, however with a solution that has not yet been mentioned:
In my case the problem could not be be pinpointed to a single file. However, it was clearly connected to a single svn revision.
The solution in such a case is to skip fetching the bad revision. This can be achieved by calling git svn fetch with the -r option. For instance, if r42 is the bad revision, and you have already fetched all revisions up to r41, just do
git svn fetch -r43
followed by
git svn fetch
to bring your git repository up to date. Of course, the obvious downside of this approach is the hole in the history that you get, but I think it's better to have a small hole in the history than to do without a working git svn clone.
For us, the problem was missing files in the SVN history (probably disk corruption). Any operation including a file whose most recent change was from the missing section of the history would fail with this "could not read chunk size" error, or an invalid XML error (depending on the operation). Fortunately we had a backup which included the missing files. Restoring them fixed the problem.
I had similar issues, for which 'svnadmin recover' did indeed magically fix things.
On another repo, it would not... Using the Versions SVN client (MacOSX) I could see that the commit user name of some files in misbehaving directories was '###ERROR###' - these dirs were giving me the "Secure connection truncated" issue on update. Simply 'moving' the files that had this marker into another directory and back (on the server, via the Versions SVN client), was enough to remove the ###ERROR### marker and enable successful update.
My colleagues and me had the same issue and what we did to fix it:
fsck (our server Linux distro runs).svnadmin validate /path/to/repository.After these steps the problem has been solved.
i had the same problem, i use TortoiseSVN and VisualSVN, the problem is in one of your commits, but is difficult to know which one it is, the solution for me was delete and create the repository in VisualSVN then do the same to the "checkout folder" on my pc, after this, copy the project to the folder and make the "second firts commit" :) but will lost all previous commits.
