Re: "400 Bad Request" on commit with 1.7 client to 1.7 server
On 1 dez, 22:29, Mark Phippard wrote: > > Subversion Edge does not have the location block for SVN in the > httpd.conf file. Have you customized the configuration files beyond > this? There is no reason you should have to add that directive > anyway. > > Assuming you are using the default configuration that SVN Edge writes, > which I know works properly, have you defined any authz rules in the > "Access Rules" section of the Repositories tab? If so, maybe > temporarily replace the rules with: > > [/] > * = rw > > And see if that solves anything. I'm having the same problem but I'm not using Subversion Edge. I'm using the CollabNetSubversion-server-1.7.0-2 RPM package. The problem occurs trying to commit either via https or http. Setting "LogLevel debug" doesn't show anything usefull in the log file. My connection is direct, with no proxy in between client and server. My Location directive is this: DAV svn SVNPath /l/home1/svn/admin/admin Require user gustavo The authentication is configured in a directive using LDAP. The authentication works because I can checkout, ls, and update the repository. It seems that it's just the commit that is causing problems. I've tried to use a AuthzSVNAccessFile directive in the location and set the authz file so that my user (gustavo) have full rights, but it didn't solve the problem. I don't have any other idea... Gustavo.
Issue with upgrade/server move to 1.7.1
Hi guys Today I've moved my SVN repository from 1.5.1 to 1.7.1, located on a new server. Having done this, I've upgraded the repositories served and am getting an odd error when testing. On the server, I'm running: svnserve -d -r /home/svn --foreground --listen-port 3690 When I try to check out or commit on one of my clients: svn co svn://toejamfootball/redwire/templates svn: Network connection closed unexpectedly On the server, I'm seeing the following: svnserve: subversion/libsvn_subr/dirent_uri.c:956: svn_dirent_join: Assertion `svn_dirent_is_canonical(component, pool)' failed. I've had a look through previous mailing list posts, tried two different versions of subversion for my target OS (CentOS 6) and have found no solution or clues on how to address this. Any thoughts? This is a bit of a 'blocking' issue and, in my mind, needs to be posted to the bugs database. Thanks, Justin -- Redwire Design Limited 54 Maltings Place 169 Tower Bridge Road London SE1 3LJ www.redwiredesign.com
chakra linux binary packages
im not sure if this is the place for this, but i was browsing the downloads/packages page @ http://subversion.apache.org/packages.html and saw chakra linux was missing. if at all possible, could someone add a section for us? a logo image: http://chakra-linux.org/wiki/images/thumb/7/7a/Chakra-gradient.png/64px-Chakra-gradient.png the i686 binary: http://www.chakra-project.org/repo/core/i686/subversion-1.6.17-1-i686.pkg.tar.xz the x86_64 binary: http://www.chakra-project.org/repo/core/x86_64/subversion-1.6.17-1-x86_64.pkg.tar.xz the package manager instructions: # pacman -S subversion thanks for your time :)
Re: "400 Bad Request" on commit with 1.7 client to 1.7 server
I straced the httpd daemon to try to get any hint. The last syscalls
before the error are these:
17748 read(18, "POST /admin/!svn/me HTTP/1.1\r\nUs"..., 8000) = 441
17748 stat("/l/home1/svn/admin/htdocs/admin/!svn/me", 0x7fffce99c130)
= -1 ENOENT (No such file or directory)
17748 lstat("/l", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
17748 lstat("/l/home1", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
17748 lstat("/l/home1/svn", {st_mode=S_IFDIR|0775, st_size=4096, ...})
= 0
17748 lstat("/l/home1/svn/admin", {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
17748 lstat("/l/home1/svn/admin/htdocs", {st_mode=S_IFDIR|0775,
st_size=4096, ...}) = 0
17748 lstat("/l/home1/svn/admin/htdocs/admin", 0x7fffce99c130) = -1
ENOENT (No such file or directory)
17748 write(9, "[Sun Dec 04 14:58:00 2011] [debu"..., 207) = 207
17748 semop(5996545, 0x2b526524e160, 1) = 0
17748 semop(5996545, 0x2b526524e16c, 1) = 0
17748 semop(5996545, 0x2b526524e160, 1) = 0
17748 semop(5996545, 0x2b526524e16c, 1) = 0
17748 write(9, "[Sun Dec 04 14:58:00 2011] [debu"..., 133) = 133
17748 write(9, "[Sun Dec 04 14:58:00 2011] [debu"..., 158) = 158
17748 open("/l/home1/svn/admin/admin/db/current", O_RDONLY) = 20
17748 fcntl(20, F_GETFD)= 0
17748 fcntl(20, F_SETFD, FD_CLOEXEC)= 0
17748 read(20, "1\n", 4096) = 2
17748 close(20) = 0
17748 writev(18, [{"HTTP/1.1 400 Bad Request\r\nDate: "..., 226}, {"http://svn2.cpqd.com.br/svn/xpto/trunk
$ svn ci -mx
svn: E175002: Commit failed (details follow):
svn: E175002: Server sent unexpected return value (500 Internal
Server Error) in response to POST request for '/svn/xpto/!svn/me'
This time the following line appeared in the error.log:
[Sun Dec 04 15:05:37 2011] [info] [client 192.168.100.37] Access
granted: 'gustavo' POST xpto:
[Sun Dec 04 15:05:37 2011] [error] [client 192.168.100.37]
(20014)Internal error: Can't open file '/l/home1/svn/admin/repos/svn/
format': No such file or directory
Here there's something strange. The repository is in /l/home1/svn/
admin/repos/xpto but the path shown in the log message substitutes
'repos/svn' for 'repos/xpto'.
The apache configuration is this:
DAV svn
SVNParentPath /l/home1/svn/admin/repos
SVNListParentPath on
AuthzSVNAccessFile /l/home1/svn/admin/admin/conf/authz.txt
Stracing this commit show the following:
17757 read(18, "POST /svn/xpto/!svn/me HTTP/1.1\r"..., 8000) = 444
17757 stat("/l/home1/svn/admin/htdocs/svn/xpto/!svn/me",
0x7fffce99c150) = -1 ENOENT (No such file or directory)
17757 lstat("/l", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
17757 lstat("/l/home1", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
17757 lstat("/l/home1/svn", {st_mode=S_IFDIR|0775, st_size=4096, ...})
= 0
17757 lstat("/l/home1/svn/admin", {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
17757 lstat("/l/home1/svn/admin/htdocs", {st_mode=S_IFDIR|0775,
st_size=4096, ...}) = 0
17757 lstat("/l/home1/svn/admin/htdocs/svn", 0x7fffce99c150) = -1
ENOENT (No such file or directory)
17757 write(9, "[Sun Dec 04 14:54:18 2011] [debu"..., 207) = 207
17757 semop(5996545, 0x2b526524e160, 1) = 0
17757 semop(5996545, 0x2b526524e16c, 1) = 0
17757 semop(5996545, 0x2b526524e160, 1) = 0
17757 semop(5996545, 0x2b526524e16c, 1) = 0
17757 write(9, "[Sun Dec 04 14:54:18 2011] [debu"..., 133) = 133
17757 write(9, "[Sun Dec 04 14:54:18 2011] [debu"..., 168) = 168
17757 write(9, "[Sun Dec 04 14:54:18 2011] [info"..., 95) = 95
17757 open("/l/home1/svn/admin/repos/svn/format", O_RDONLY) = -1
ENOENT (No such file or directory)
17757 write(9, "[Sun Dec 04 14:54:18 2011] [erro"..., 163) = 163
17757 writev(18, [{"HTTP/1.1 500 Internal Server Err"..., 236}, {"
Re: "400 Bad Request" on commit with 1.7 client to 1.7 server
Just one more information. I was using the packages CollabNetSubversion-extras and CollabNetSubversion-server version 1.7.0-2. I've just upgrade them to version 1.7.1-1 but the problems remain. -- Gustavo.
SlikSVN (but also Tortoise SVN) crashes when trying to merge/reintegrate branch to Trunk
Hi, TortoiseSVN , but also the command-line SVN crash when I try to merge back a branch in the Trunk. I attach the log file as well as the Dump file. Because of my company's policy, we are still using SVN 1.6.xx . Please tell me if I can provide you with any useful information, Best regards, M. Thibaud Desodt This message has been scanned for malware by SurfControl plc. www.surfcontrol.com svn-crash-log20111202144036.dmp Description: svn-crash-log20111202144036.dmp svn-crash-log20111202144036.log Description: svn-crash-log20111202144036.log
SVN 1.7.1
Hi. I'm using it since official release. And decision to using it was my big fail. Becase: 1. commit list makes about 10 minutes time after time; 2. first update in day last over 15 minutes; I'm working on big project (over 100 000 files) and waste about an hour on waiting SVN operations. And the saddest thing that this operations takes my HDD off and now I have no time to back to the old SVN version. All my programms and IDEs are very busy within updating process. I hope you'll fix yours problems with new version but I'll also try to solve it on my working place by ubdating OS and all drivers. Thanks.
Re: SVN 1.7.1
On Fri, Dec 2, 2011 at 2:19 AM, i_maliavko wrote: > Hi. > > I'm using it since official release. And decision to using it was my big > fail. Becase: > 1. commit list makes about 10 minutes time after time; > 2. first update in day last over 15 minutes; > > I'm working on big project (over 100 000 files) and waste about an hour on > waiting SVN operations. And the saddest thing that this operations takes my > HDD off and now I have no time to back to the old SVN version. All my > programms and IDEs are very busy within updating process. I hope you'll fix > yours problems with new version but I'll also try to solve it on my working > place by ubdating OS and all drivers. > > Thanks Ouch. I'm a friendly list contributor, not a core developer, but perhaps I can offer a thought or two. What OS are you using? CIFS accessed filesystems with lots of files have been a historical headache, so if you're using a Windows box with a network share, you may be really hurting on that basis. Why does the project have 100,000 files? Should it be factored into smaller chunks for *other* reasons? Which network protocol are you using to access the repository? I've been pushing svn+ssh for security reasons, but encryption itself can be a significant computational burden in large data transfers.
Re: SVN 1.7.1
On Fri, Dec 2, 2011 at 8:19 AM, i_maliavko wrote: > Hi. > > I'm using it since official release. And decision to using it was my big > fail. Becase: > 1. commit list makes about 10 minutes time after time; > 2. first update in day last over 15 minutes; Hard to say whether this is a regression, without having a comparison with your old version. How long did 1.6 take in these scenarios? And: which OS and filesystem? > I'm working on big project (over 100 000 files) and waste about an hour on > waiting SVN operations. And the saddest thing that this operations takes my > HDD off and now I have no time to back to the old SVN version. All my > programms and IDEs are very busy within updating process. I hope you'll fix > yours problems with new version but I'll also try to solve it on my working > place by ubdating OS and all drivers. 1.7 seems to be slower for some operations when the working copy is on a network drive (NFS, CIFS, ...). Is this the case? If so, can you try and compare it to a similar working copy on a local drive? Also: maybe try running 'svn cleanup' on the entire working copy. (SVN keeps track in its metadata of last-modified times of the files. If both the last-modified time and filesize are still the same, SVN assumes the file is unchanged. Otherwise, it will always read+checksum the entire file to determine if it is still unchanged, which is quite a bit slower. Sometimes the metadata of the timestamps isn't correct anymore, for instance because the working-copy was copied (without preserving last-modified times), or because something 'touched' it. Obviously this can give a serious performance hit. 'svn cleanup', among other things, restores the correct timestamps in the metadata.) -- Johan
Re: Issue with upgrade/server move to 1.7.1
Fixed on #svn, right? Justin Finkelstein wrote on Sun, Dec 04, 2011 at 16:24:30 +: > Hi guys > > Today I've moved my SVN repository from 1.5.1 to 1.7.1, located on a new > server. Having done this, I've upgraded the repositories served and am > getting an odd error when testing. > > On the server, I'm running: > > svnserve -d -r /home/svn --foreground --listen-port 3690 > > When I try to check out or commit on one of my clients: > > svn co svn://toejamfootball/redwire/templates > svn: Network connection closed unexpectedly > > On the server, I'm seeing the following: > > svnserve: subversion/libsvn_subr/dirent_uri.c:956: svn_dirent_join: > Assertion `svn_dirent_is_canonical(component, pool)' failed. > > I've had a look through previous mailing list posts, tried two different > versions of subversion for my target OS (CentOS 6) and have found no > solution or clues on how to address this. > > Any thoughts? This is a bit of a 'blocking' issue and, in my mind, needs > to be posted to the bugs database. > > Thanks, > > Justin > > -- > Redwire Design Limited > > 54 Maltings Place > 169 Tower Bridge Road > London SE1 3LJ > www.redwiredesign.com >
Re: chakra linux binary packages
Please send a patch against the site source: http://subversion.apache.org/patches http://svn.apache.org/repos/asf/subversion/site Drake Justice wrote on Sat, Dec 03, 2011 at 14:34:10 -0500: > im not sure if this is the place for this, but i was browsing the > downloads/packages page @ http://subversion.apache.org/packages.html and > saw chakra linux was missing. if at all possible, could someone add a > section for us? > > a logo image: > http://chakra-linux.org/wiki/images/thumb/7/7a/Chakra-gradient.png/64px-Chakra-gradient.png > the i686 binary: > http://www.chakra-project.org/repo/core/i686/subversion-1.6.17-1-i686.pkg.tar.xz > the x86_64 binary: > http://www.chakra-project.org/repo/core/x86_64/subversion-1.6.17-1-x86_64.pkg.tar.xz > > the package manager instructions: # pacman -S subversion > > thanks for your time :)
Re: Subversion 1.7.1 Migration
Guten Tag PR, am Sonntag, 4. Dezember 2011 um 00:53 schrieben Sie: > Accessing the new server from the 1.4.6 client any thing to keep > in mind or any one has faced any issues? If you access via http, SVNAdvertiseV2Protocol off may be of interest if you recognize any problems with your old clients. > I am hoping the dev Team sees no issues accessing the server > from 1.4.6 clients ? The clients should be compatible, as far as I read. > Any reports on stability of the new 1.7.1 .. As far as I can see the most problems where with client updates and corrupted working copies. > In general any other suggestions and hints or any other things that > need to be taken care of ? Backups. ;-) Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon.030-2 1001-310 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow
