Re: Could not read chunk size: connection was closed by server
On Fri, Nov 18, 2011 at 3:27 PM, Justin Johnson wrote: > Hi, > > We are running Subversion 1.6.16 and Apache 2.2.17 on Solaris 10, with > 1.6.12 clients connecting from Windows and various flavors of UNIX. > For as long as I can remember users on Windows and UNIX clients have > been getting the following error every once in a while, typically > during a checkout. > > Could not read chunk size: connection was closed by server > > In the server logs the following errors appear around the same time. > > Provider encountered an error while streaming a REPORT response. [500, #0] > A failure occurred while driving the update report editor [500, #130] > Error writing base64 data: Software caused connection abort [500, #130] > > When the error happens you can generally just do an update in the > working copy and it will pick up where it left off. > > The frequency of this error has been increasing lately so I'm trying > again to determine the cause. Numerous people have posted about it > online, but none of the solutions have seemed applicable to my > situation. For example, there are no signs of too many open file > descriptors and I have verified that the repositories are not corrupt. > The time that it takes for the checkout to fail with this error shows > no linkage with our timeout settings in Apache as far as I can tell. > Sometimes it fails after about 20 seconds... other times 180 or so. > For what it's worth, the only two timeout settings we have are: > > TimeOut 1800 > KeepAliveTimeout 10 > > This page seemed potentially related, but I'm not sure. Our Solaris > box is actually a Sun zone, so there's some virtualization involved. > > http://pve.proxmox.com/pipermail/pve-user/2009-December/001087.html > > Does anyone have any suggestions? > > Thanks. > Justin > While researching this problem further I came across http://stackoverflow.com/questions/772894/updating-from-svn-repository-returns-could-not-read-chunk-size-error, where one user said the following. I eventually solved the problem by using the apache2-mpm-prefork package rather than the apache2-mpm-worker package I also found http://serverfault.com/questions/194233/use-prefork-or-worker-in-apache-configuration, where one user said the following. Are you doing things with Apache modules (SVN, PHP are two examples)? In that case prefork might be safer. Is it true that mpm worker is not safe for use with Subversion? Could that possibly be related to this problem? I see no mention of this in the svn book or the README or INSTALL files that come with Subversion.
[ANN] SubGit Early Access Program Build #789
Hello All, Let me introduce our new project: SubGit (http://subgit.com/). SubGit is a free tool for smooth migration from Subversion to Git. As well as from Git to Subversion. Without git-svn insanity. It works like this: - Install SubGit into your repository on the server side - Let initial translation complete (time depends on the size of repository) - Committers may now use either Git or Subversion (or both) with the tools of their choice SubGit EAP builds are free to use builds which you may try and let us know what do you miss, so that we make sure that all the features you need are included into the final version of SubGit. SubGit works on Linux, Windows or OS X and requires Java 5 or newer.Download new SubGit EAP build from http://subgit.com/ Alexander Kitaev, TMate Software, http://subgit.com/ - Two-way ticket to the dark side. http://svnkit.com/ - Java [Sub]Versioning Library! http://hg4j.com/ - Java Mercurial Library! http://sqljet.com/ - Java SQLite Library!
Sparse branches
Hi, I understand sparse checkouts but is there a recommended way of doing 'sparse branches'? Often projects need to be farmed out to a release branch and then deleted from the main trunk (to save space). It is then necessary to do the inverse on the new branch ie delete all the projects that are not necessary on the branch (obviously its not necessary but its nicer for performance and disk space). Is this the only way of doing it or is it possible to be cleverer with the copy so that only the minimum is copied in the first place? Could a simple merge relationship be maintained if the project was not deleted from the trunk? (I worry about mergeinfo...) Cheers, James
Re: Sparse branches
On Tue, Nov 22, 2011 at 11:30 AM, James French wrote: > > I understand sparse checkouts but is there a recommended way of doing > ‘sparse branches’? Often projects need to be farmed out to a release branch > and then deleted from the main trunk (to save space). It is then necessary > to do the inverse on the new branch ie delete all the projects that are not > necessary on the branch (obviously its not necessary but its nicer for > performance and disk space). > Maybe you should move the trunk/branches/tags under each project instead of combining things under the same trunk. If you need to pull components from several projects back together you can always do it with externals. -- Les Mikesell lesmikes...@gmail.com
"400 Bad Request" on commit (mod_dav_svn)
Hi everyone, Since upgrading the svn client to 1.7.1 (following the server's upgrade to the same version), we are getting the following error when doing a commit: svn: E175002: Commit failed (details follow): svn: E175002: Server sent unexpected return value (400 Bad Request) in response to POST request for '/xxx/!svn/me' This happens on a freshly-checked out working copy. We are using Apache as a front-end (mod_dav_svn). A commit done via the file system is successful. Any ideas on what's going on? Aleksandr Sidorenko Administrateur systèmes/réseaux • System/Network Administrator Espeo Inc. 2000, ave McGill College, bureau 230 Montréal, Québec (H3A 3H3) www.espeo.com asidore...@espeo.com 514-905-1268 #234
Re: "400 Bad Request" on commit (mod_dav_svn)
On 2011-11-22, at 16:09 , Aleksandr Sidorenko wrote: > Hi everyone, > > Since upgrading the svn client to 1.7.1 (following the server's upgrade to > the same version), we are getting the following error when doing a commit: > >svn: E175002: Commit failed (details follow): >svn: E175002: Server sent unexpected return value (400 Bad Request) in > response to POST request for '/xxx/!svn/me' > > This happens on a freshly-checked out working copy. We are using Apache as a > front-end (mod_dav_svn). A commit done via the file system is successful. > > Any ideas on what's going on? Reading from another thread ([BUG/REGRESSION] mod_dav_svn service stopped working…), adding the following line to the directive does seem to fix the problem: SVNAdvertiseV2Protocol off Does anyone know if this breaks/affects anything else?
Re: Could not read chunk size: connection was closed by server
Justin Johnson writes: > during a checkout. > > Could not read chunk size: connection was closed by server > > In the server logs the following errors appear around the same time. > > Provider encountered an error while streaming a REPORT response. [500, #0] > A failure occurred while driving the update report editor [500, #130] > Error writing base64 data: Software caused connection abort [500, #130] The server failed to write to the client and the client failed to read from the server. Looks like a network problem caused the connection to be shut down. To diagnose it you probably need to capture a network trace of some sort. -- Philip
Re: Problem with compiling Perl bindings (1.6.17) on PowerPC
Justin Hibbits writes: > I tracked it down to the building of libsvn_swig_perl-1.a, and > swig_util_pl.c is compiled without -fPIC, which is required to build shared > libraries on PowerPC. Manually adding '-fPIC' to the COMPILE_SWIG_PL line > in the top-level Makefile (line 180) fixed this. But, in this, I noticed > there is no usage of a SWIG_PL_COMPILE, while there is a SWIG_PY_COMPILE > and SWIG_RB_COMPILE. Subversion uses "perl -MExtUtils::Embed -e ccopts" to determine which flags to use. Is the problem a fault with Subversion or your Perl installation? If you want to try writing a patch then look at build/ac-macros/swig.m4. -- Philip
Re: "400 Bad Request" on commit (mod_dav_svn)
Aleksandr Sidorenko writes: > Since upgrading the svn client to 1.7.1 (following the server's > upgrade to the same version), we are getting the following error when > doing a commit: > > svn: E175002: Commit failed (details follow): > svn: E175002: Server sent unexpected return value (400 Bad Request) in > response to POST request for '/xxx/!svn/me' > > This happens on a freshly-checked out working copy. We are using > Apache as a front-end (mod_dav_svn). A commit done via the file system > is successful. > > Any ideas on what's going on? What is in the apache error log? -- Philip
Re: "400 Bad Request" on commit (mod_dav_svn)
On 2011-11-22, at 18:49, "Philip Martin" wrote: > Aleksandr Sidorenko writes: > >> Since upgrading the svn client to 1.7.1 (following the server's >> upgrade to the same version), we are getting the following error when >> doing a commit: >> >>svn: E175002: Commit failed (details follow): >>svn: E175002: Server sent unexpected return value (400 Bad Request) in >> response to POST request for '/xxx/!svn/me' >> >> This happens on a freshly-checked out working copy. We are using >> Apache as a front-end (mod_dav_svn). A commit done via the file system >> is successful. >> >> Any ideas on what's going on? > > What is in the apache error log? There was nothing in the error log. The access log showed the 400 response.
Re: "400 Bad Request" on commit (mod_dav_svn)
Aleksandr Sidorenko writes: >> What is in the apache error log? > > There was nothing in the error log. The access log showed the 400 response. Perhaps you need to adjust the logging level? Subversion generates several different HTTP_BAD_REQUEST errors and the error log should identify it. -- Philip
