RE: Issues to close

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:stefan_at_egosoft.com]
Sent: maandag 9 mei 2016 10:54
To: dev_at_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