9

after trying to merge changes to an svn trunk back to the branch with the following command:

../branches/myBranch$ svn merge -r 94:171 https://.../trunk --dry-run

I get the following error from SVN:

svn: REPORT of '/svnroot/simspark/!svn/vcc/default': Could not read chunk size: Secure connection truncated (https://simspark.svn.sourceforge.net)

We already tried to google this for quite a while and concluded that this is kinda pointless. I won't stop you from trying yourself of course, but you have been warned.

Anyway, the general vibe of what we found is that this is a bug in to SVN and we are screwed. I'm using SVN version 1.5.4, which is the newest version available for my Linux distribution.

Any ideas? I don't feel like losing more than three months of work, so a solution would be quite nice.

A colleague who just tried this on a Mac did not get the error and could pull off the dry-run, by the way, but already has a few dozen conflicts, and still counting. <3 SVN.

aheld
  • 313
  • 1
  • 5
  • 11
  • I got this problem today - not doing a merge, but a switch - will post an answer if I find something useful. For now, am having success working on individual folders instead of the whole tree. Check out http://help.beanstalkapp.com/discussions/problems/533-could-not-read-chunk-size-secure-connection-truncated – GrahamMc Jun 02 '10 at 07:25
  • 2
    I had this issue on Ubuntu while trying to merge/commit large amount of data. It turned out VPN is gets reset on Ubuntu. While the same thing was tried on Windows it went flawlessly. I think the VPN client for Ubuntu was resetting after sending about 1MB of data to SVN server. Not sure if I said anything worthwhile. But, just sharing my experience. – Nishant Jan 25 '11 at 20:48
  • Nishant, please post that as an answer - it might not be the solution to this question, but it might be a good clue for someone else. – pjmorse Feb 02 '11 at 13:46
  • I received the same error message try to update to HEAD. I solved it by checking out a fresh copy of the repo then copying modified files over to it. Could possibly have created a patch file to make it easier, but was "corrupt" working copy was already almost up-to-date anyway. – AlexMA May 09 '13 at 13:25

5 Answers5

2

A solution that worked for me (on a local server, where I had access) was to add to the Apache configuration file the SVNAllowBulkUpdates On directive. Might be of help for somebody ;)

M_TS
  • 21
  • 1
2

For what it's worth, I've found that this happens when your HTTP connection is reset by your firewall. Using svn+ssh solves the problem, if that's an option for you.

Ken Kinder
  • 12,654
  • 6
  • 50
  • 70
1

Had the same problem during a switch. Since other branches within the same repo didn't yield the same error, it was likely that the working copy somehow got broken.

Solution: first find the highest folder in the directory tree where the error occurs; that's where your working copy got broken. Once you located that folder, check it out fresh in another location on your harddrive. Within the newly checked out folder, grab the file called "entries" from the .svn subdirectory, and copy it over the entries file in your broken working copy.

jrial
  • 478
  • 4
  • 10
1

This appears to be a Sourceforge issue, not an SVN one.

https://sourceforge.net/apps/trac/sourceforge/ticket/21376 https://sourceforge.net/apps/trac/sourceforge/ticket/21051

If you add directories to your working copy, or import new directory structures into an existing repository, this seems to cause the issue.

Our workaround is to use a different SVN provider.

Mark Hall
  • 53,938
  • 9
  • 94
  • 111
Chad Lehman
  • 11
  • 1
1

Looks like the merge was too big for something along the line to handle - I reduced the revision range and was able to get around the error. This site gave me a clue: http://lists.parrot.org/pipermail/parrot-Dev/2009-September/02785.html

Stephen
  • 11
  • 1