[Tortoisehg-discuss] Bazzar stratgy regarding shell extension

Stefan Küng tortoisesvn at gmail.com
Sat Apr 19 09:31:24 BST 2008

Peer Sommerlund wrote:
> I'm crosposting this to all tortoises I know of - the Windows Overlay 
> problem is relevant to all.
> (//git-cheetah //is a tortoise in disguise)
> On 19/04/2008, *TK Soh* <teekaysoh at gmail.com 
> <mailto:teekaysoh at gmail.com>> wrote:
>     On Fri, Apr 18, 2008 at 12:34 PM, Tom Widmer
>     <tom.widmer at googlemail.com <mailto:tom.widmer at googlemail.com>> wrote:
>      >
>      > [copy of
>     http://bazaar-vcs.org/bzr/bzr.dev/doc/developers/tortoise-strategy.txt]

Nice document. But next time, before you just assume things about TSVN 
could you please ask me first?

"As soon as the FileOpen dialog is loaded, TortoiseSvn loads well over 
20 additional DLLs, including the MSVC8 runtime, into the Notepad 
process causing its memory usage to more than double - all without doing
anything tortoise specific at all."

But that doesn't mean that Windows will use double the memory. Those 
dlls are already in memory, and Notepad will use those already loaded 
dlls. Yes, the task manager shows an increased amount of memory for the 
process, but it doesn't mean that more RAM is actually used.

Also, TSVN has an option (also in the settings dialog) to enable the 
overlays and all other stuff "only in explorer". If that option is 
activated, then TSVN will *not* load all the extension dlls for other 
processes using the file-open dialog. We have a really, really small dll 
to acomplish that (project "TortoiseStub" in our source tree).

"TortoiseSvn appears to cache using a separate process, aptly named 
TSVNCache.exe. It uses a named pipe to accept connections from other 
processes for various operations. At this stage, it's still unclear 
exactly what is fetched from the cache and exactly what the shell 
xtension fetches directly via the subversion C libraries."

TortoiseSVN has three modes, which can be set in the settings dialog. 
The "default" is to use TSVNCache.exe to ask for the status to show the 
overlays. Then there's "Shell" which makes the shell extension fetch the 
svn status directly, and there's "none" which doesn't show any overlays.

The reason that the shell extension dll also has the ability to fetch 
the Subversion status directly is simply because of the "shell" setting 
for the overlays: some people don't like the cache. But since the svn 
library is written in plain C, that's not a problem.

>      >
>      > TK Soh wrote:
>      >
>      >  I'd say the document details the best strategy for TortoiseHG too,
>      >  simply by replacing BZR with HG and Bazaar with Mercurial.
>      >
>      >  Except I propose this change:
>      >
>      >  Share the exact same (eventually C++) shell overlay extension
>     for Bzr
>      >  and HG, so that if you have TortoiseHG and TortoiseBZR
>     installed, they
>      >  actually are sharing a single COM dll, which will presumably pick up
>      >  from the Windows registry the names of the RPC exe programs it
>     needs to
>      >  communicate with (one Bazaar one and one Mercurial one). There's
>     a minor
>      >  versioning issue here, but this can be solved by versioning the
>      >  capabilities of the RPC server so newer versions of the shell
>     overlay
>      >  extension don't ask unanswerable questions of older RPC servers.
>      >
>      >  If that's no go, at the very least the C++ code can be shared in its
>      >  entirety, and just built differently for HG and BZR.
>     Stefan Küng of TSVN has proposed a solution to get around the slot
>     limit of Overlay handlers among the Tortoise clients:
>       http://tortoisesvn.tigris.org/svn/tortoisesvn/TortoiseOverlays/version-1.0.1/Documentation.txt
> username guest
> password <empty>
>     Eventually TortoiseHg, and probably all other Tortoise clients too,
>     will adopt this approach.
> I think that the TortoiseOverlay component could evolve into a separate 
> project, were some of the features mentioned in the bzr tortoise 
> strategy (space-efficient DLL architecture, separate tortoise-processes) 
> would fit nicely, and benefit all tortoises.

I'm not sure what exactly you want to improve here. You can't just use 
one shell extension dll for all Tortoise clients - they're made for 
different versioning tools and have very few things in common.
Apart from the overlays (which are limited and therefore a common 
extension should be preferred if possible, i.e., if the overlay icons 
can be used by your specific version control system), why would you want 
to merge other stuff too?

For example, the context menu extension is different for every Tortoise 
client. The same for the column provider.

If you want to have some common status-fetching process, that wouldn't 
work either: different version control systems have different status and 
also work completely different.

> I would like to contribute to such a project, but I would rather watch a 
> dedicated mailing list.
> The amount of mailing lists posts I'm trying to follow has reached my 
> processing capabilities, so adding two more (TSVN and TBZR) with a 
> fairly high amount of posts that are not relevant to me is not too 
> attractive.
> Anybody feel like setting up such a project?

First, please explain exactly what you want to achieve and how you would 
want to do this.


   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080419/e66a9a61/attachment-0001.pgp 

More information about the bazaar mailing list