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 \'/s
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.
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 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.
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.
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.