On Tue, Apr 2, 2019 at 10:20 PM Daniel Shahaf <d...@daniel.shahaf.name> wrote: > > Christoph Vogtländer wrote on Tue, 02 Apr 2019 09:02 +00:00: > > This is reproducible. Running with de_DE.UTF-8 (my default LANG), svn > > will try to submit the change but runs into a time-out. Running with > > en_GB.UTF-8, svn fails with error 413. > > > > Why is subversion acting differently with different language setting on > > the client side? > > > > I'm not sure, especially given that both locales are UTF-8 ones.
Perhaps the difference between your first and second attempt is not caused by different language settings, but because the working copy was in a different state? For instance, if the "base" of your working copy is full of mixed revisions, and you're committing a lot of changes on top of that, the "edit report" that's sent by the client to the server can be much larger (thus hitting some limit on the server). Maybe try to execute another 'svn update' on your entire working copy so it gets a uniform revision. > A few > shots in the dark: > > - Try '-F /dev/null' instead of '-F svn-commit.tmp'. > - Is there any non-ASCII in the output of `svn st -q`? (`svn st -q | sed > 's/[ -~]//g' | grep .`; that's left bracket, space, minus, tilde, right > bracket) > - Try LC_ALL=C and LC_ALL=C.UTF-8. > > > Any ideas what can be done to successfully commit the changes? > > Depends. If you want to make the changes in one commit, you'll need to > increase the timeouts in server and client sufficiently (that includes > any proxies). A workaround is to separate the changes to several > commits: use 'svn commit -- ./foo ./bar' instead of 'svn commit -- ./'. Just another hint to get you started: the client-side timeout can be found in the file ~/.subversion/servers on your client machine. Look for "http-timeout = ..." (the default is 60 (seconds) I believe). Also, on the server-side, the httpd directive LimitXMLRequestBody might be playing a role in that second error ("Request Entity Too Large"). In our setup at work we have "LimitXMLRequestBody 0" in our httpd config, to effectively have no limit (for a publicly exposed repository you should always have some limit, to avoid malicious users being able to crash your server, but if you only have internal users I think it's OK to eliminate that limit). Though I would seriously recommend splitting up your huge commit into several commits. Perhaps find some logical blocks, or split by subdirectories, or ... Huge commits can be a pain later on, for instance because every time you query the 'svn log' for one of those files later, this huge commit will be part of the result (part of its history), and with the '-v' (verbose) option 'svn log' will show all the affected paths, which will be huge ... > I'm not sure why you'd get a 413 on the request to !svn/me, though. (to > the list) Are any requests made to !svn/me other than the initial POST? Sorry, no idea. -- Johan