You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Hett <st...@egosoft.com> on 2016/05/06 11:27:22 UTC
Re: Issues to close
I'd suggest to also close the following issue:
* SVN-4557: ra_serf fails to delete directory containing many files
https://issues.apache.org/jira/browse/SVN-4557
The fix for this particular issue got in 1.9.4 and even though it's
not yet backported to the 1.8 branch, the described issue is fixed in
1.9 now.
--
Regards,
Stefan Hett
Re: Issues to close
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 9 May 2016 at 12:23, Bert Huijben <be...@qqmail.nl> wrote:
> The lock add issue is completely independent…This implementation was
> changed to make multiple locks atomic, instead of one at a time.
It depends of RA layer: ra_serf uses pipelining to issue multiple
single path LOCK requests without waiting for other requests to
complete, while ra_svn uses new 'lock-many' command to perform
operation in atomic way.
--
Ivan Zhakov
RE: Issues to close
Posted by Bert Huijben <be...@qqmail.nl>.
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@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
Re: Issues to close
Posted by Stefan Hett <st...@egosoft.com>.
>> 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
Re: Issues to close
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 15 May 2016 at 01:24, Stefan <lu...@posteo.de> wrote:
> On 5/9/2016 10:05, Ivan Zhakov wrote:
>
> On 9 May 2016 at 10:15, Stefan Hett <st...@egosoft.com> wrote:
>
>> On 5/6/2016 5:33 PM, Ivan Zhakov wrote:
>>
>> On 6 May 2016 at 14:27, Stefan Hett <st...@egosoft.com> wrote:
>>
>> I'd suggest to also close the following issue:
>> * SVN-4557: ra_serf fails to delete directory containing many files
>> https://issues.apache.org/jira/browse/SVN-4557
>> The fix for this particular issue got in 1.9.4 and even though it's
>> not
>> yet backported to the 1.8 branch, the described issue is fixed in 1.9 now.
>>
>> Probably, but in this case we need to file different issue for
>> *replacing* directory containing many files with locks -- this part of
>> issue not fixed.
>>
>> I take it that this is not fixed on trunk yet, right?
>>
>
> Yes, replacing directory containing many files with locks is not fixed on
> trunk.
>
> I've now created a separate issue for the replace case:
> https://issues.apache.org/jira/browse/SVN-4634
> So I take it SVN-4557 could be closed as fixed now.
>
Marked SVN-4557 as resolved. Thank you very much!
--
Ivan Zhakov
Re: Issues to close
Posted by Stefan <lu...@posteo.de>.
On 5/9/2016 10:05, Ivan Zhakov wrote:
> On 9 May 2016 at 10:15, Stefan Hett<st...@egosoft.com> wrote:
>> >On 5/6/2016 5:33 PM, Ivan Zhakov wrote:
>> >
>> >On 6 May 2016 at 14:27, Stefan Hett<st...@egosoft.com> wrote:
>> >
>> >I'd suggest to also close the following issue:
>> >* SVN-4557: ra_serf fails to delete directory containing many files
>> > https://issues.apache.org/jira/browse/SVN-4557
>> > The fix for this particular issue got in 1.9.4 and even though it's not
>> >yet backported to the 1.8 branch, the described issue is fixed in 1.9 now.
>> >
>> >Probably, but in this case we need to file different issue for
>> >*replacing* directory containing many files with locks -- this part of
>> >issue not fixed.
>> >
>> >I take it that this is not fixed on trunk yet, right?
>> >
> Yes, replacing directory containing many files with locks is not fixed on trunk.
>
I've now created a separate issue for the replace case:
https://issues.apache.org/jira/browse/SVN-4634
So I take it SVN-4557 could be closed as fixed now.
Regards,
Stefan
Re: Issues to close
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 9 May 2016 at 10:15, Stefan Hett <st...@egosoft.com> wrote:
> On 5/6/2016 5:33 PM, Ivan Zhakov wrote:
>
> On 6 May 2016 at 14:27, Stefan Hett <st...@egosoft.com> wrote:
>
> I'd suggest to also close the following issue:
> * SVN-4557: ra_serf fails to delete directory containing many files
> https://issues.apache.org/jira/browse/SVN-4557
> The fix for this particular issue got in 1.9.4 and even though it's not
> yet backported to the 1.8 branch, the described issue is fixed in 1.9 now.
>
> Probably, but in this case we need to file different issue for
> *replacing* directory containing many files with locks -- this part of
> issue not fixed.
>
> I take it that this is not fixed on trunk yet, right?
>
Yes, replacing directory containing many files with locks is not fixed on trunk.
> 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.
> 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?
--
Ivan Zhakov
Re: Issues to close
Posted by Stefan Hett <st...@egosoft.com>.
On 5/6/2016 5:33 PM, Ivan Zhakov wrote:
> On 6 May 2016 at 14:27, Stefan Hett <st...@egosoft.com> wrote:
>> I'd suggest to also close the following issue:
>> * SVN-4557: ra_serf fails to delete directory containing many files
>> https://issues.apache.org/jira/browse/SVN-4557
>> The fix for this particular issue got in 1.9.4 and even though it's not
>> yet backported to the 1.8 branch, the described issue is fixed in 1.9 now.
>>
> Probably, but in this case we need to file different issue for
> *replacing* directory containing many files with locks -- this part of
> issue not fixed.
I take it that this is not fixed on trunk yet, right?
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.").
So if I got all the details right, should I go ahead and create the two
issues in JIRA so #4557 can be closed?
--
Regards,
Stefan Hett
Re: Issues to close
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On 6 May 2016 at 14:27, Stefan Hett <st...@egosoft.com> wrote:
> I'd suggest to also close the following issue:
> * SVN-4557: ra_serf fails to delete directory containing many files
> https://issues.apache.org/jira/browse/SVN-4557
> The fix for this particular issue got in 1.9.4 and even though it's not
> yet backported to the 1.8 branch, the described issue is fixed in 1.9 now.
>
Probably, but in this case we need to file different issue for
*replacing* directory containing many files with locks -- this part of
issue not fixed.
--
Ivan Zhakov