Den mån 26 juli 2021 kl 17:50 skrev John Abraham <j...@theabrahams.ca>:
> Hello, I’ve finally figured out the situation in which my subversion > client pins the CPU at 100% and never moves beyond it. And hence I’d like > to report a bug. > > Sometimes the server hangs up the connection, in my case with this error > on the server log: > > "Working copy path 'hey it's a file still.txt' does not exist in > repository [404, #160013 > ]” > > Then the client keeps spinning at 100% forever (15+ hours) and never > reports an error to the user. In particular if a filename recorded on the > client doesn’t match a file name on the server. > > Client version > Client on OSX version is > svn, version 1.14.1 (r1886195) > compiled Jul 5 2021, 18:28:42 on x86_64-apple-darwin19.6.0 > > > Our server is a bit old, Ubuntu SVN server 1.9.3. Perhaps newer servers > normally hang up more gracefully, with a message to the client? But still, > we think this should be classified as a client bug, since the client is the > one pinning the end user’s CPU at 100% forever and not saying anything > about it. > > > > BACKGROUND (how we found it and how to reproduce it) > > We had an Nginx server in front to the SVN server. And we were doing svn > mv on a file with spaces in the filename. From the client, we did this > command > > svn mv hey\ it\'s\ a\ file.txt hey\ it\'s\ a\ file\ still.txt > > Which was showing up on the server logs as > > COPY mrsgui-test:/test_space/hey it's a file.txt > mrsgui-test:/test_space/hey%20it's%20a%20file%20still.txt > > In other words, the server was seeing a different copy command than the > client was sending, due to the Nginx controller in front of the svn server > deciding to escape some spaces to %20. > > Obviously our test case isn’t subversion’s fault. BUT we think it’s a bug > that the SVN client keeps spinning the CPU at 100% forever if the server > decides to hang up for this reason (or perhaps for other reasons?). > > *** > > Am I supposed to create a ticket for this? Or send it to the dev list? It > took us a long time to figure this out, hoping to save someone else the > trouble. > > Thanks! > Thanks for reporting in such detail! Is there any chance you can capture the network traffic on your client? Ie what the server is actually returning. Kind regards, Daniel Sahlberg
