TortoiseSVN checkout errore non riuscito svn: E120106: ra_serf: il server ha inviato un corpo di risposta HTTP troncato

Question

TortoiseSVN mostra l'errore svn: E120106: ra_serf: The server sent a truncated HTTP response body durante l'operazione di checkout. Come risolvere il problema?

Answer 1

Quindi effettuare l'aggiornamento anziché eseguire nuovamente il check-out ... Non eliminare la copia estratta, aggiornarla nuovamente.

Answer 2

Alcuni ideas da TortoiseSVN sviluppatore:

The data sent is too big and the server closes the connection due to reaching a limit.

Possible steps which can help fix this issue:

• Increase the timeout value on the server
• set compression level to zero on the server (will make everything slower but helps with this issue)
• make sure all proxies that are in between you and the svn server also have the timeout values increased

Answer 3

SVN 1.8 includes a new HTTP client library (Serf).

che credo sia responsabile di questo. Avevo installato TortoiseSVN-1.8.6.25419-x64-svn-1.8.8.msi e l'esecuzione di svn merge ha dato lo stesso errore. Inizialmente, penso che sia un problema con i timeout del server SVN ma la stessa operazione di unione ha funzionato con 1.6. Quindi credo che il problema sia con SVN versione 1.8 e successive. Si prega di ripristinare la versione del client svn su 1.7 o 1.6 e provare!

Answer 4

Impostare il seguente valore-chiave nel file di configurazione SVN. Questo è tutto.

DeflateCompressionLevel 5 

1 è il valore più basso. 9 è il valore massimo.

Answer 5

Assicurarsi di utilizzare la versione del client Subversion più recente e aggiornata disponibile. Se il problema persiste, si dovrebbe

• rivolgersi all'amministratore di sistema di controllare la rete per problemi di connessione,
• garantire che un proxy si può avere tra la macchina client e il server Subversion funziona correttamente e non si uccide la connessione prematuramente,
• assicura che un antivirus installato sul client o sul computer server non interferisca con il traffico di Subversion HTTP (S). È necessario aggiungere una regola di eccezione/esclusione che disabiliti l'accesso o la scansione del traffico da e verso il server Subversion.

NOTA:declassamento client Subversion è una soluzione sbagliata e brutta. Il problema deve essere risolto sulla rete.

Answer 6

Ho riscontrato lo stesso problema, ma nel contesto del nostro teamcity di sistema CI. piuttosto che usare teamcity per il checkout, alcuni script eseguono il checkout svn manuale e hanno causato questo errore.

Internal SVN clean checkout canceled on large repositories for working copy format 1.7 using the svn.exe via script instead of build-in teamcity SVN with the message: "svn: E120106: ra_serf: The server sent a truncated HTTP response body."

• pulita cassa di piccole repository funziona indipendentemente dal lavoro formato copia
• cassa pulita di grandi repository di opere utilizzando lavoro formato copia 1,5
• utilizzando l'esportazione invece di cassa funziona
• utilizzando TeamCity 8.1. 5 svn interno client funziona (nessuna idea del perché)
• utilizzando svn client 1.7 invece di 1.8 risultati in un analogo errore di timeout correlato: "svn: E175002: REPORT di '/!svn/me ': Impossibile leggere corpo di risposta: Connessione sicura troncato"

Aumentare il valore di timeout SVN sul server ha effettivamente risolvere il problema e non la 'ra_serf', né la 'connessione troncata errore' sicuro verificati dopo .

Aniket Thakur suggestione di un ritorno della versione client svn ha avuto effetto su questo problema, ma non sono riuscito a trovare la versione giusta. (se ce n'è uno)

Sanmat Jhanjhari suggerimento di diminuire il livello di compressione è non solo parte della soluzione accettata, ma il motivo per cui questo potrebbe funzionare è che mantiene il tempo di risposta tra server SVN e clien t costante e la compressione di file di grandi dimensioni non causa più timeout.

cambiare la copia di lavoro in 1.5 è una parte del client alternativa alternativa che si potrebbe prendere per risolvere questo problema. il motivo per cui questo funziona è probabilmente correlato al modo in cui i dati vengono compressi, ma non sono riuscito a capire le ragioni esatte.

utilizzando l'esportazione è un'alternativa lato client terribile che si potrebbe prendere nel caso in cui si è interessati ai dati stessi e non è necessario che sia un repository. il comportamento di esportazione è leggermente diverso. per esempio non sovrascrive i file esistenti. Inoltre non sono riuscito a capire perché funzioni rispetto al normale checkout.

Answer 7

Impostazioni proxy errate possono causare lo stesso messaggio di errore.

Ho riscontrato esattamente lo stesso errore in diversi momenti durante il checkout. I primi file sono sempre riusciti, ma dopo 5-10 file è apparso l'errore ra_serf. Lo stesso è successo con file grandi e piccoli.

Dopo alcune prove ed errori (altro hardware, connessione cablata) non ero più vicino a una soluzione. Ho deciso di controllare tutte le impostazioni SVN di Tortoise e ho trovato la risposta semplice: le mie impostazioni proxy non erano corrette!