The lock add issue is completely independent… This implementation was changed
to make multiple locks atomic, instead of one at a time. The user issue of
locking ‘hundreds of thousands of files’ at once, was just something we never
designed this system for.
The delete and replace issues are related. We found the delete problem many
releases ago and designed a workaround that worked around the limitation by
using a not-standard request. But this only works for deletes where usually the
body is ignored. Once you have a proppatch (= property change) or replacement
the body is used for actual data and we can’t put lock tokens in there.
The real fix for delete, replace, etc. of trees with many locks is to somehow
allow the headers to go through, but this requires a config change from the
admin. (Or using HTTP/2, as that has a more relaxed header limit)
The only thing that makes all these related is that we never designed for a
‘lock a complete tree’ scenario in Subversion. And I still don’t know why users
really want this, as with Subversions implementation it doesn’t really help you
in any scenario.
Bert
From: Stefan Hett [mailto:ste...@egosoft.com]
Sent: maandag 9 mei 2016 10:54
To: dev@subversion.apache.org
Subject: Re: Issues to close
In that case I take it that there should also be yet another created issue
pointing out that lock and add operations are bugged in 1.9 (as far as I
followed the commits, these are fixed on trunk however) (see users list:
"Problem with locking multiple files.").
As far I understand this is completely different problem. As far I
understand it's related to "Java-SSL-Tunnel" and I have no idea what
is it.
As far as I was following the story behind #4557 the underlying implementation
change in SVN is that multiple locks (and also deletes/adds?) were now
presented in the http-header rather than in the http-body (which was the case
in < 1.9). That in combination with the reduction of the default max
header-section size in Apache httpd led to the described issue in #4557.
Since that case could be triggered using the SVN command line client, to users
it was a regression for the case of deleting multiple files and therefore was
fixed in 1.9.4 for that particular situation (aka: deleting multiple paths).
The same underlying issue however still persists for locks/adds in 1.9.4.
However, these are only noticeable issues for API users. So if I make use of
the API to lock multiple files, SVN >= 1.9 would create a longer http-header
section than 1.8 did which then in combination with the http-header-limit
setting would cause my call to fail with 1.9, while it succeeds with 1.8.
Independent from what might have caused the "Java-SSL-tunnel" issue, this to me
sounds like a "bug" from an API user's point of view.
So if I got all the details right, should I go ahead and create the two
issues in JIRA so #4557 can be closed?
Just to confirm: what two new issues do you mean? As far I understand
one is about problem committing directory replacement, but what is the
other?
Issue 1:"replacing directory containing many files with locks"-issue (the one
you mentioned)
Issue 2: "ra_serf fails to lock/delete multiple files" (aka: the case described
above).
--
Regards,
Stefan Hett
