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?
Simon
--
: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2394386
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-09-14 01:41:22 CEST