[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Time to switch to 1.7 libs?

From: Simon Large <simon.tortoisesvn_at_googlemail.com>
Date: Mon, 14 Sep 2009 00:41:23 +0100

2009/9/13 Stefan Fuhrmann <stefanfuhrmann_at_alice-dsl.de>:
> Stefan Küng <tortoisesvn_at_gmail.com> wrote:
>> > Sorry, my bad. The path settings somehow pointed
>> > to an older version. SVN 1.7 is still SLOW!
>> So I did my own tests. And the speed is ridiculous. I can confirm your
>> timings, and on windows they're even worse (not much, but still worse).
>> An update of the TSVN working copy takes about five minutes, while using
>> up 100% CPU the whole time.
>> I've sent a mail to the svn dev list. If this doesn't improve soon, I'll
>> just skip svn 1.7 and wait for 1.8 (if ever). Or I'll start a new
>> project, because with this 'improvement', it's no fun anymore to work on
>> TSVN and Subversion.
> I was thinking of sending a post in that thread, too.
> But then it may not have helped to to calm people down
> and I had not much time this WE for a real discussion
> either.
> IMHO, rewriting the wc libs is The Right Thing to do.
> If that should fail, SVN would be at a dead end anyway
> because so much depends on it.
> Therefore, their current strategy of concentrating on
> getting this done, is certainly valid. Based on Hyrums
> post, there will be a drastic improvement as soon as
> the last old API usage has been removed, i.e. without
> the need of additional optimization.
> Our problem is that we can't switch the main line until
> that point is reached around New Year. That would limit
> the update & stabilization phase to about 2 months.
> My understanding is that there are few new features in 1.7.
> However, we may need to adapt the "working copy detection
> code", i.e. everything that looks for a .svn folder today.
> To not completely stall 1.7 development, I propose the
> following:

But how much of TSVN 1.7 depends upon Sunbersion 1.7? Which of those
new features do we really need at the moment?

> * open a 1.7-dev branch that basically contain the patch
>  you made to get the 1.7 API working

Branching early rings alarm bells because you end up merging
everything. Twice the work for how much gain?

> * get info from the SVN devs how the final wc detection
>  should work and migrate the current code towards it

Can I suggest simply refactoring so there is a single bit of code
which does the WC detection. When the time comes it is then a small
job to change the detection method in one place rather than many.

> * adapt to other API changes as well
> 1.7-dev would be coding only with no extensive tests etc.
> So, by the time the libs approach usability, we would have
> most of the code changes available and had a fair chance
> to stabilize it and to report eventual issues to the SVN devs.
> That way, the worst thing that could happen would be that
> some of the 1.7 features don't make it in TSVN 1.7.
> Side-note: Switch to VS2010 no earlier than for 1.8?
> Thoughts?


:       ___
:  oo  // \\      "De Chelonian Mobile"
: (_,\/ \_/ \     TortoiseSVN
:   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
:   /_/   \_\     http://tortoisesvn.net
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-09-14 01:41:22 CEST

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.