"Could not read response body: Secure connection truncated. Reasons, risks, possible fix for this error"
If you get this error, chances are you work on big or very big svn project. The result of this error is often a broken svn operation and the working copy state, which must be treated very careful. The problem lies on the server side, and we try some solutions right now. Here is what I have learned.
What causes the error
- That is an error on svn server side, so probably no sense to change anything on client.
Some info on our current config: We run on CentOS with Apache 2. We had this error on 1.6.11 and still have it after upgrade to 1.6.13.
We presume, it is a buffer overflow issue, but fixes we know of didn’t help us.
- The second possible reason is a synchronization failure between SVN and Apache which causes the break of network connection. In any case, larger data files and huge svn dirs tend to cause the error.
And here is some more theory on reasons of the problem:
When will the error occur
Any svn operation which involves large data transfer over network. More time your svn operation takes, more risk that you get Secure connection truncated.
update are definitely at risk.
What can you do
There is a fix suggestion which works for some folks:
This didn’t work for us though… We could only minimize the damage by learning the particular risks because of this error
What risks you need to be aware of
svn switch corruption, very high risk
One thing which can occur: your working copy might irrecoverably corrupted because of the break in the middle of the
Some directories will point to the new switched svn path and some to the old. The problem is here that your svn doesn’t see it as a problem.
Better clean checkout. If you get “Secure connection truncated” during switch, the working copy is most likely damaged beyond repair. Don’t try to restore it unless you 100% sure what you do. The risk is you will commit changes on many svn locations on the server without even knowing it.
Release build chain, CI, etc
If you have delivery deadlines which involve svn operations, they are all endangered. You plan to ship your code tomorrow and go home because you know that integration is running automatically and code is good.
You may have nothing tomorrow because of svn failure. We have our integrator working at night just to make sure that shipment will take place next day…