svn_client_upgrade and speed

Hi,

Once again I tried upgrading TSVN to the svn trunk. While the transition
requires a lot of work, this isn't my concern. But after playing a while
with the new version, I have two concerns, one minor but one very
serious one:

first the minor one:
svn_wc_upgrade() only upgrades one working copy, but ignores all
externals. We have users who have hundreds (yes, that's correct:
hundreds!) of externals set in their working copies. While I certainly
don't recommend such a setup, it happens.
But even if there are only a few externals, it's a real pain to upgrade
all those external working copies one at a time.
So my suggestion: please provide another parameter 'includeexternals'
for svn_wc_upgrade() so that the externals can be upgraded in the same step.
Sure, I could write something in TSVN like this:
1) upgrade
2) fetch status
3) filter the externals
4) upgrade externals
5) repeat for every external (goto 2)
but that would take much longer than necessary since svn_wc_upgrade()
already has the information about the externals (the properties are
converted too).

And now the real concern: the speed is completely unacceptable. Waiting
five minutes for an update that takes maybe 25 seconds with 1.6.x is
something no user will accept. I've reported this two times before, and
a lot of time has passed since then. But the speed has not improved at all.

The TSVN working copy has a few externals. An update on the wc root
first takes more than a minute for TSVN itself, using up all available
CPU and basically slowing down the whole system, sometimes even to a
point where other applications stop working (if my mp3 player stops
every few seconds, I'm not happy at all). Then the externals get updated
and once again, for every external it takes about a minute or more with
100% CPU usage.

Seriously, this is not just a minor inconvenience. This is a major
problem and must be fixed as soon as possible. Because no matter what
new features this new wc format provides, no one will use it if it's
that slow. And in my opinion, it's not good to first address all the
features and then try to improve the speed: what if it later turns out
that it can't get faster? I'm afraid that this will be the case - it's
been almost half a year since I first reported this, and in all this
time it didn't improve at all (at least not as far as I can tell).

If this doesn't improve soon, I won't link TSVN with svn 1.7 but stay
with version 1.6. With version 1.7, I would lose all users very quickly.

And no, I'm not exaggerating here. This is a serious problem.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2393723