RE: Issues to close
From: Bert Huijben <bert_at_qqmail.nl>
Date: Mon, 9 May 2016 11:23:14 +0200
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.
From: Stefan Hett [mailto:stefan_at_egosoft.com]
In that case I take it that there should also be yet another created issue
As far I understand this is completely different problem. As far I
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
Just to confirm: what two new issues do you mean? As far I understand
Issue 1:"replacing directory containing many files with locks"-issue (the one you mentioned)
-- Regards, Stefan HettReceived on 2016-05-09 11:23:37 CEST
This is an archived mail posted to the Subversion Dev mailing list.