Re: sunversion 1.8.0 crash on FreeBSD when WC path is symlink (regression) (not a FreeBSD specific!)
Hello, Lev. You wrote 21 июня 2013 г., 22:08:44: LS Here is way to crash subversion 1.8.0 release on FreeBSD -- try to LS update WC which is symlink to real WC. It worked in 1.7.x. Repository LS and access scheme and repo's content doesn't matter, serf repo is LS used for illustration, but it crashes with any repo and any scheme LS (https, svn, etc). Problem is not FreeBSD-specific, here is output on CentOS 6 x86_64 [root@centos6 tmp]# llh | grep svn [root@centos6 tmp]# mkdir svn [root@centos6 tmp]# svn co -q svn://svn.freebsd.org/base/releng/9.1/ svn/ [root@centos6 tmp]# svn up svn/ Updating 'svn': At revision 252113. [root@centos6 tmp]# ln -s svn svn2 [root@centos6 tmp]# llh | grep svn drwxr-xr-x 23 root root 4,0K Июн 23 14:54 svn lrwxrwxrwx 1 root root 3 Июн 23 14:56 svn2 - svn [root@centos6 tmp]# svn up svn2/ Updating 'svn2': Ошибка сегментирования (core dumped) [root@centos6 tmp]# uname -a Linux centos6.local 2.6.32-358.11.1.el6.centos.plus.x86_64 #1 SMP Wed Jun 12 19:12:17 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux [root@centos6 tmp]# gdb GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-redhat-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. (gdb) core core.8284 Missing separate debuginfo for the main executable file Try: yum --disablerepo='*' --enablerepo='*-debug*' install /usr/lib/debug/.build-id/09/cc47f079f7a61aa6453cf81ccf093da013bd2d [New Thread 8284] Core was generated by `svn up svn2/'. Program terminated with signal 11, Segmentation fault. #0 0x7f6110bd67b0 in ?? () (gdb) bt #0 0x7f6110bd67b0 in ?? () #1 0x in ?? () -- // Black Lion AKA Lev Serebryakov l...@freebsd.org
Re: sunversion 1.8.0 crash on FreeBSD when WC path is symlink (regression) (not a FreeBSD specific!)
On Sun, Jun 23, 2013 at 04:28:25PM +0400, Lev Serebryakov wrote: Hello, Lev. You wrote 21 июня 2013 г., 22:08:44: LS Here is way to crash subversion 1.8.0 release on FreeBSD -- try to LS update WC which is symlink to real WC. It worked in 1.7.x. Repository LS and access scheme and repo's content doesn't matter, serf repo is LS used for illustration, but it crashes with any repo and any scheme LS (https, svn, etc). Problem is not FreeBSD-specific, here is output on CentOS 6 x86_64 I can reproduce this on OpenBSD, too. Can you please file an issue? See http://subversion.apache.org/reporting-issues.html Thanks!
Merge error with SVN 1.8.0
Hi, I've tried upgrading the client to SVN 1.8, and now see some strange merge errors while reintegrating the branch. According to http://subversion.apache.org/docs/release-notes/1.8.html#auto-reintegrate the --reintegrate option is now deprecated, its use is discouraged and SVN should be able to figure that out automatically. However, when I tried a plain svn merge, it gave me the following error: [aneyman@build2 trunk]$ svn merge ^/MERGE-PATH svn: E210002: Unable to connect to a repository at URL 'svn://MERGE-URL' svn: E210002: Network connection closed unexpectedly Strangely, 'svn merge --reintegrate' worked fine. We are running 1.6.11 on the server (stock RedHat RPM, 1.6.11-2.el6_1.4 version). I installed SVN 1.8.0 RPM from WanDisco (1.8.0-1) on the client. Any clues/suggestions as to how to debug this further? Regards, Alexey.
ra_serf PROPFIND refused by Nginx
Hi list, I recently switched from svn 1.7 to 1.8 and with it, from neon to serf. I am now getting the following error for many repositories: % svn co http://svn.mkgmap.org.uk/mkgmap/trunk svn: E175004: The PROPFIND response did not include the requested properties Wireshark tells me that this is because the PROPFIND request was refused by the server with HTTP error 411, length required. Even though the server claims to support HTTP 1.1, chunked transfer encoding does not appear to work. The server identifies itself as Nginx, which leads me to believe that I am dealing with a reverse proxy. I worked around the issue by modifying subversion/libsvn_ra_serf/util.c to force HTTP 1.0: - /* HTTP/1.1? (or later) */ - if (sl.version != SERF_HTTP_10) -handler-session-http10 = FALSE; Clearly, always forcing HTTP 1.0 is not the right solution. But maybe svn should automatically switch to HTTP 1.0 when it receives a 411 response to a chunked request, telling it that the server (or a proxy) does not support chunked transfers? - Bartosz
Error - 411 Length Required (on Commit)
.I'm not on the list and couldn't find this in archive search...please cc me on any responses...thx! Was going to report this error over at the TortoiseSVN site, but apparently they are pointing over here. Here's the link to the discussion over on Tortoise: http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061dsMessageId=3058859 Here's the text from over there (which includes repro, etc.). For me, same repro as below, and it's a simple matter of trying to commit anything and I get the 411 Length Required error as detailed below (i.e. me too). I'm running Win7 64 bit, latest patches, etc. = This is the right mailing list to report issues with TortoiseSVN. However, as the problem also occurs with the standard subversion command line client then the problem has to lie within the subversion library rather than any of the TortoiseSVN code. In case you are not aware, TortoiseSVN along with all other subversion clients is built on top of the standard subversion library which is provided by the subversion project itself. TSVN just provides the user-friendly front end. You can contact the subversion team on users at subversion.apache.org. Simon I’m running on Vista 32 bit and have been upgrading Tortoise for years successfully until now. REPRO · Update to 1.8.0 from 1.7 · Update local working copy · Modify a file and attempt to commit RESULT POST of '/svn/[project name]/!svn/me': 411 Length Required ==
Re: Merge error with SVN 1.8.0
On Sun, Jun 23, 2013 at 3:56 PM, Alexey Neyman sti...@att.net wrote: Hi, I've tried upgrading the client to SVN 1.8, and now see some strange merge errors while reintegrating the branch. According to Did you delete the old RHEL 1.6.11 RPM, to avoid libraries lying around and confusing you? Or binaries turning up in your commit scripts due to inherited PATH that does not include the new version? To avoid the fun and games, I urge you to grab and test my newly minted Subversion 1.8.0 RPM building tools, at: https://github.com/nkadel/subversion-1.8.x-srpm I've also bundled a libserf SRPM building toolkit at: https://github.com/nkadel/libserf-1.2.x-srpm I've been testing out the 1.8.x features, it's suitable for pushing to Rpmforge. EPEL would take a lot more work because there are key libraries, like SQLite, that have to be compiled locally even for RHEL 6. And Fedora 19, which is coming out, does not use SysV init scripts at all, it uses system, so the svnserve init script will be rejected out of hand. http://subversion.apache.org/docs/release-notes/1.8.html#auto-reintegrate the --reintegrate option is now deprecated, its use is discouraged and SVN should be able to figure that out automatically. However, when I tried a plain svn merge, it gave me the following error: [aneyman@build2 trunk]$ svn merge ^/MERGE-PATH svn: E210002: Unable to connect to a repository at URL 'svn://MERGE-URL' svn: E210002: Network connection closed unexpectedly Strangely, 'svn merge --reintegrate' worked fine. We are running 1.6.11 on the server (stock RedHat RPM, 1.6.11-2.el6_1.4 version). I installed SVN 1.8.0 RPM from WanDisco (1.8.0-1) on the client. Any clues/suggestions as to how to debug this further? Regards, Alexey.
Re: Apache Subversion 1.8.0 Released (An appropriate version of serf could not be found)
On Wed, Jun 19, 2013 at 12:29 AM, Nico Kadel-Garcia nka...@gmail.com wrote: On Tue, Jun 18, 2013 at 2:23 PM, Thomas Harold thomas-li...@nybeta.com wrote: And the last hurdle I had to jump over to get svn 1.8.0 to compile on my CentOS 6 box. When running ./configure, I had the following message show up: It's not in any of the repositories, and Fedora is still trying to figure out how to lay it out. (Use /usr/include/*.h, or /usr/include/serf-1/*.h for the files). In the meantime, you're quite welcome to my RPM building tools at https://github.com/nkadel/libserf-1.1.1-srpm and at https://github.com/nkadel/subversion-1.7.9-srpm. I've published updates for both of these: https://github.com/nkadel/libserv-1.2.x-srpm https://github.com/nkadel/subversion-1.8.x-srpm I'm tagging those as particular releases get updated, enjoy. And yes, it's a bit weird to be publishing Subversion integration tools aover at Github, but I don't have write access to create branches in the main Subversion code repository. (And I don't currently want it.)
Re: Merge error with SVN 1.8.0
On Sunday, June 23, 2013 07:20:50 PM Nico Kadel-Garcia wrote: On Sun, Jun 23, 2013 at 3:56 PM, Alexey Neyman sti...@att.net wrote: Hi, I've tried upgrading the client to SVN 1.8, and now see some strange merge errors while reintegrating the branch. According to Did you delete the old RHEL 1.6.11 RPM, to avoid libraries lying around and confusing you? Or binaries turning up in your commit scripts due to inherited PATH that does not include the new version? Sorry for being unclear: I only upgraded the CLIENT, not the server. The server still has 1.6.11. And yes, sorry for stating the obvious, the 1.7.10 subversion RPM was removed when I installed 1.8.0. To avoid the fun and games, I urge you to grab and test my newly minted Subversion 1.8.0 RPM building tools, at: https://github.com/nkadel/subversion-1.8.x-srpm Are you calling RPMs provided by WanDisco's fun and games? I think Subversion developers employed by WanDisco might be somewhat insulted by such judgment. Is there something wrong with RPMs from WanDisco that I must, in your opinion, switch to your version? I've also bundled a libserf SRPM building toolkit at: https://github.com/nkadel/libserf-1.2.x-srpm Thanks. I thought that my original email indicated that we're using svn:// protocol and thus serf is out of the equation. In other words: do you have anything relevant to say regarding the reported issue, rather than advertising your work? Regards, Alexey. I've been testing out the 1.8.x features, it's suitable for pushing to Rpmforge. EPEL would take a lot more work because there are key libraries, like SQLite, that have to be compiled locally even for RHEL 6. And Fedora 19, which is coming out, does not use SysV init scripts at all, it uses system, so the svnserve init script will be rejected out of hand. http://subversion.apache.org/docs/release-notes/1.8.html#auto-reintegrate the --reintegrate option is now deprecated, its use is discouraged and SVN should be able to figure that out automatically. However, when I tried a plain svn merge, it gave me the following error: [aneyman@build2 trunk]$ svn merge ^/MERGE-PATH svn: E210002: Unable to connect to a repository at URL 'svn://MERGE-URL' svn: E210002: Network connection closed unexpectedly Strangely, 'svn merge --reintegrate' worked fine. We are running 1.6.11 on the server (stock RedHat RPM, 1.6.11-2.el6_1.4 version). I installed SVN 1.8.0 RPM from WanDisco (1.8.0-1) on the client. Any clues/suggestions as to how to debug this further? Regards, Alexey.
Re: SVNADMIN Crashes
On Sun, Jun 23, 2013 at 8:16 PM, Bob Melucci bob.melu...@claritydesign.com wrote: SVNAdmin Crashes with upgrade command- see attached dumps. Any help would be appreciated You've probably run into this bug: http://svn.haxx.se/users/archive-2013-06/0143.shtml
