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
