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

Re: [TSVN] Performance issue caused by unversioned files/folders in WC

From: Michael Dietschi <groups_at_dietschi.net>
Date: 2004-12-15 17:21:09 CET

On Wed, 15 Dec 2004 16:20:51 +0100, SteveKing <steveking@gmx.ch> wrote:

> Michael Dietschi wrote:
>> But if I do not have the "Show unversioned files" checkbox checked then
>> there
>> are no files shown which could be added. If I want a file to get added
>> _then_
>> I will check "Show unversioned files" and know that I have to wait for some
>> minutes...
> That was before. Then people complained that it took too long to 'just'
> show the unversioned files and that TSVN should get them the first time,
> store them in memory and immediately show them if you check "show
> unversioned files". So I changed it to be what it is now.

Ouch! _I_ would vote for the previous version ;) Seriously, what's the common
case? I think people more often want to commit their changes to already
versioned files and not to add some new files.

>>> If you do not want to process that folder, you should
>>> add the folder to the ignore list, then performance will be what you
>>> want.
>> I'll have to check that option...
> That's would be good anyway, even if you don't have performance issues.
> Even subversion will be a lot faster if you set the svn:ignore property
> for unversioned folders.

I just added some folders to the ignore list but that's a bit messy because
a lot of these folders are 'intermediate' ones which are created by the CE
Platform Builder and some others have always to be there but not under
revision control. So there are some _huge_ 'svn:ignore's... :(
...and maybe sometime a file deep in the directory tree _will_ get versioned.


To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Dec 15 22:49:09 2004

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.