[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: Stefan Fuhrmann <stefanfuhrmann_at_alice-dsl.de>
Date: Sun, 13 Sep 2009 23:21:42 +0200

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:

* open a 1.7-dev branch that basically contain the patch
  you made to get the 1.7 API working
* get info from the SVN devs how the final wc detection
  should work and migrate the current code towards it
* 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?

-- Stefan^2.

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2394355

To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-09-13 23:21:58 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.