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

Re: [TSVN] RFC: New cache scheme

From: Will Dean <svn_at_indcomp.co.uk>
Date: 2005-01-23 10:43:39 CET

At 16:53 21/01/2005 +0100, you wrote:

>Now that I had a look at your code, I suggest moving it to trunk.

I'm flattered!

>Since we have to split up the shell extension part anyway (property page
>and overlay/column handler) we can keep the original shell extension as
>long as the other stuff doesn't work well enough.
>We just create three new projects:
>- TSVNCache (already done)
>- TortoiseOverlay.dll (for the overlay/column handlers)
>- TortoisePPage.dll (for the property page)
>The TortoiseSVN.dll (the existing dll) is kept until the three new
>projects are working good enough to be tested by those using the nightly

That sounds pretty good. I'd make two suggestions/modifications:

1. Instead of producing TortoiseOverlay.dll initially, we just make some
very minor modifications to it to allow a *run time* selection of whether
it fetches from SVN directly, or uses the TSVNCache system. This could be
a registry flag, cached with your normal registry-caching system. It would
be a minor change to SVNFolderStatus and to the Overlay handler.

This would allow people to switch between the new and old cache very
easily, if there were problems. I don't think this would be a high-risk
modification to the shell extension. If we were ever happy with the
external cache, we could then remove the SVN code from the shell-extension.

2. If we are going to split the shell extension up into PropPage and
others, could we take the opportunity to slightly upgrade their
implementation? I would suggest that we went to ATL, at least for the
PPage, and made the DLL self-registerying. This would simplify the WiX
install script (fewer GUIDs in there), and would make development a little
easier (it would be easy to switch between multiple locations for the DLLs,
for example)
I also am slightly unconvinced of the correctness of some aspects of the
current COM object implementation (ref-counting is not MP-Safe for example).

I would like to hold-off merging to the trunk just for a bit longer, as I
am not happy with the way that directory status is handled at the moment,
and am in the middle of a re-write.



To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sun Jan 23 10:44:16 2005

This is an archived mail posted to the TortoiseSVN Dev mailing list.