On Thu, May 18, 2017 at 8:22 PM, Branko Čibej <brane_at_apache.org> wrote:
> On 18.05.2017 16:21, Andrey wrote:
>> Stefan Sperling <stsp_at_elego.de> писал(а) в своём письме Thu, 18 May
>> 2017 15:55:36 +0300:
>>
>>> And this, we have to admit, can be a problem for some use cases.
>>> It would be nice to have an optimized way of doing this,
>>> and I expect we would be open to suggestions and patches.
>> I tested it a bit deeper.
>> I checked out entire directory for the 1193 revision on the drive
>> (took ~6 seconds) and recall the command w/o "-r <rev>" (took ~1 second).
>> I don't think this is about optimization because (i checked it) the
>> server is not so busy to hangs about 1 minute. Is it much like
>> excessive search somethere?
>
> You're making assumptions about the implementation without actually
> looking at it. As Bert said, we don't have an optimized code path for
> recursive search of properties in the repository. It's as simple as that.
Agreed.
Though it's interesting to know that "checkout + recursive propget on
working copy" is an order of magnitude faster than "recursive propget
on url". It illustrates the impact of this non-optimized code path.
So, for the time being you could use this as a workaround, Andrey (if
you're scripting this): checkout to a temp directory (or even a
ramdisk if it's not too big), and run the propget on that; then delete
the checkout.
Also, extra help is always welcome here, Andrey. So if you think this
optimization is really important, and you have some time and interest,
we'd certainly welcome a patch to improve this. [1]
[1] See http://subversion.apache.org/docs/community-guide/general.html#patches
--
Johan
Received on 2017-05-18 21:55:34 CEST