>> can we have the battleship grey back, please?
> Settings->General, uncheck "Use Aero dialogs".
Ahhhh. That's better. Thanks.
>> please make Overlays work consistently on Win 7 x64?
> We're trying.
I noticed! That's why I installed the nightly, I wanted to see if any of the
recent changes being discussed had been implemented and if so, whether they
made any difference for me. The 16 image limit seems to be a problem,
especially when you consider that TortoiseXxx isn't the only set of apps to
use icon overlays - lots of offsite backup tools use them also (DropBox,
Mozy, etc...). Have you considered raising a case on the Microsoft Connect
site to get them to increase the limit? I am sure that TortoiseXxx
(especially TSVN) has a large enough developer base to put some real
pressure on MS if enough people vote for it.
>> Or maybe have a *single* instance of TSVNCache rather than one for x86
and another for x64.
> Could *maybe* be done, but the x64 and win32 versions use the same struct,
but due to the different word lengths those structs actually have different
sizes.
Is the communication between Explorer and TSVNCache in-proc, then? If it's
out of proc, it would be fairly straight forward to have a fixed-width
serialization format, no? Or perhaps it would it be feasible to use a
Windows API-style approach of having a byte or two at the front of the
struct to indicate what size it is?
>> How about making TSVN (or more likely TSVNCache) recognise that a WC on a
path containing a junction is actually the same as another WC on a path
*without* a junction. Just sayin'...
> Tell that the svn guys (or better: the apr guys).
I should point out that the thing I'm trying to avoid here is having the
same subtree traversed twice for caching purposes (or four times on a 64bit
OS). I don't understand why the windows-specific part of the tool (i.e.
TSVN) shouldn't be the piece to do that given that it is the thing that
makes the call to the SVN/APR API in the first place. Presumably TSVN
watches for file changes then, if a file change is in a WC, makes
appropriate calls to cache the status for Explorer? If that's the case, then
surely 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 given that the same
file change will also have been triggered (or is about to be triggered) on
the real path. Likewise, when Explorer requests the status from TSVNCache,
it could map the request to the real path before it does the lookup? No
changes in SVN or APR necessary with this approach. I accept that I could be
way-off base here, but I'm interested to hear your opinion.
Thanks in advance.
TTFN,
Damian.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2461140
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-03-17 16:02:58 CET