Re: E175012 and E175002 when trying to commit

On Tue, Apr 2, 2019 at 10:20 PM Daniel Shahaf <d.s_at_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