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

[Stefan Küng]

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* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:

    On Fri, Apr 18, 2008 at 12:34 PM, Tom Widmer
    <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
     >
     > [copy of
    http://bazaar-vcs.org/bzr/bzr.dev/doc/developers/tortoise-strategy.txt]

anything tortoise specific at all."

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

Anybody feel like setting up such a project?

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.

Stefan

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

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

signature.asc
Description: OpenPGP digital signature