Johan Corveleyn <jcor...@gmail.com> писал(а) в своём письме Thu, 18 May
2017 15:51:01 +0300:
Why just not to ignore them? Anyway they are don't have any mapping to a
local directory.
In general I think it's fine for a directory to have an empty
svn:externals property (have not tested it, but I guess it's fine). So
the property is there, but has no content. That's not the problem.
When you request "svn propget svn:externals -R $URL" the client and
server still have to do the work to retrieve that property from all
nodes in the entire subtree -- it doesn't matter whether it's empty or
not at this point (it doesn't even matter whether it's defined or not,
they still have to look it up).
To rule out any relation to "svn:externals" in itself, can you test if
you get the same "propget -R" performance if you retrieve another
property with exactly the same command?
For instance, try:
svn pget fooprop "https://domain.ab/svn/proj2/trunk@1193"; -R
--non-interactive
Ok, i see your point. Yes, the svn:ignore works the same way and nothing
to do with these 2 "external records".
On my svn repository that command takes also a minute or 2 for a
reasonably large tree.
So even without any property defined anywhere, your "propget -R"
request still makes the client (and/or server) crawl the entire
subtree and requesting the property at every node, and this seems to
take a lot of time (like Bert said, "There is no optimized code path
for retrieving properties recursively directly from the server.")
Ok. May be a --depth option for the "svn co" command like "--depth
directories"
to workaround this for script writers?
I am writing script to collect these externals and seems 1-2 minute of
waiting one directory of about (i've opened it in the Repository Browser
and took a look on the depth of directories there, it took 5 seconds) ~100
subdirectories and ~400 files is not worth to wait so long. So i suggest
some command to take all these
externals on the drive as is w/o files, for example, in to the TEMP
directory to traverse it offline.
I don't know, but why is not? At least it could reduce server disk work or
something.
