Could not read chunk size. Error in SVN

Question

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!

Leatherwood

did you run "svnadmin recover" on the repository? – Adherence

Yes, I did, it says: svnadmin: Recovery completed. But when checkout same error. – Leatherwood

Check the VisualSVN Server logs. There are located in Event Viewer -> Application and Services -> VisualSVN Server – Gram

We've just had this. Our SVN server had to be restored from a backup because of a failure, so our local copies were more up to date. We were trying to commit e.g. revision 1220 but the server (because of the restore) was only at e.g. 1215. The 'chunk size' error was what the client produced, but checking the event viewer gave us more clues about the revisions being out of sync. – Antislavery

Answer 1

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.

Yarvis

Answer 2

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.

Forejudge

Answer 3

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.

Harve

Answer 4

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.

Proctoscope

How does one identify which revision it is stuck on? – Oleta

@JaySullivan That is the tricky part: The output of git svn fetch does not show the revision at which the error occurred, so you have to rely on git svn fetch to fetch revisions in order. I think, unless you have the log of the first git svn fetch around, which contains the last revision number that was successfully fetched, there are only two ways to find out: 1. check the svn-revisions for all the fetched branches via git svn find-rev, or 2. restart the whole git svn cloning process to get back that log. Sorry, I don't know a better way. – Proctoscope

This works with svn2git tool. I needed to skip a broken rev just run git svn fetch -rXX then relaunch svn2git – Worsley

Answer 5

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.

Ci

Answer 6

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.

Brandebrandea

Answer 7

My colleagues and me had the same issue and what we did to fix it:

1. On the svn server we checked partition filesystem with repository for errors with fsck (our server Linux distro runs).
2. Copied repository directory to backup.
3. Validated repository via svnadmin validate /path/to/repository.

After these steps the problem has been solved.

Mullens