Re: [Tortoisehg-discuss] Bazzar stratgy regarding shell extension

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.

Stefan

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