We have installed svn mirror plugin in staging environment of Bitbucket to know the complete functionality of svn mirror.while working on this plugin we getting the error
Command failed
chunk stream ended unexpectedly
The error “chunked stream ended unexpectedly” is reported when an SVN server closes connection on server-side timeout. In practice, that means that response to the client’s (SVN Mirror) update request is large and takes client long time to process. Requests are something like “give an information on how to update from revision N to revision X” and response includes all the information about changes.
Usually, the first recommended thing such a case is to set svn.httpSpooling to true in the mapping configuration: this option tells the add-on to write the response to a hard drive prior to processing it.
Another helpful step is to exclude large files — like big binaries *.iso files or similar — from the translation, it will help to decrease response size and thus resolve the issue.
If your SVN is being accessed over http/https through Apache web-server, there’s an option to increase the server-side timeout in SVN Apache configuration (see Apache Timeout directive).
Finally, such an issue may be caused by incorrect branches and tags mapping, so it would worth to re-think the mapping scheme and exclude some erroneous branches from the translation.
SVN Mirror add-on’s settings can be set right in the Subversion Branches Mapping text field on the Branches Mapping tab in the add-on setting of a specific repository:
The web server settings should be applied on the web server itself, most probably in the web server software configuration files (e.g., Apache’s configuration files).
I am also having the same issue as being reported here and changing the option of httpSpooling or adding exclusion does not resolve the issue. Also, we don’t have access to the SVN server so we cannot modify the timeout options.
According to the post, there is an option to optimize the network traffic, does it imply that excluded files won’t be downloaded? I think that this option would resolve our problem. If so, can you share the option (either privately or here).
thank you for pointing at that, you are completely right, by default the excludePath option does not limit the traffic as the exclusion happens on the SubGit side. The option that allows changing this behaviour is svn.optimizeExcludePath and it can be set like this:
[svn]
…
svn.optimizeExcludePath = true
Note, however, that the setting only changes behaviour for explicit patterns, most of the wildcard patterns will not be affected due to SVN protocol specifics.
Thank you for providing the option. It works!
Even though our exclusions are only wildcard expressions, it looked enough to allow the synchronization to be successful and was really fast compared to when the option was not specified.