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

RE: Suggestions

From: Damian Powell <damian_at_shadow-angel.com>
Date: Thu, 18 Mar 2010 11:55:32 -0000

Hi Stefan,

>> Have you considered raising a case on the Microsoft Connect site...
> That won't happen. The limit is actually not in Explorer but in the list
control and image list.
> http://blogs.msdn.com/oldnewthing/archive/2009/12/09/9934348.aspx

Okay fair enough, I still think it's worth raising on Connect though, even
if MS do their usual thing of closing it as 'By Design', otherwise, it will
*definitely* never get considered.

>> Is the communication between Explorer and TSVNCache in-proc, then? If
>> it's out of proc, it would be fairly straight forward to...
> I know how to do it. But it requires a lot of work and data conversion.

I have no doubt you know how to do it! I'm just nudging you to consider it.
I'm prepared to help out if you can be persuaded it's worthwhile.

>> TSVN could crawl up the tree (or remember) to see if a file is on a
junction or not - if it
>> is, then throw the call away...
> Checking every path whether it is a junction or not is completely out of
the question here.
> That would cause a major performance decrease (and I mean *major*).

You wouldn't need to crawl the directory hierarchy for every file though,
nor even every directory. You only need to know if the root of this working
copy is on a path which contains a junction (or susbt drive). That
particular information could be cached in-memory, easily, at low cost. While
it's true that the number of versioned files on a user's HDD may be in the
hundreds of thousands, it is unlikely that the total number of working
copies would be more than tens, or possibly hundreds of items and so it
would be relatively inexpensive.



To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-03-18 12:55:46 CET

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.