Re: Suggestions

On 17.03.2010 16:02, Damian Powell wrote:

>>> 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,

It's a limit of 15, not 16.

> 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.

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

>>> 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?

I know how to do it. But it requires a lot of work and data conversion.

>>> 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

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*).

Also, that wouldn't help with SUBSTed drives since there's no junction.

If you use junctions or SUBSTed drives, just put one of the paths into
the ignore list.

Stefan

-- 
        ___
   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=2461287
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].