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

Stefan Küng tortoisesvn at gmail.com
Mon Apr 21 17:37:52 BST 2008

Peer Sommerlund wrote:
> On 19/04/2008, *Stefan Küng* <tortoisesvn at gmail.com 
> <mailto:tortoisesvn at gmail.com>> wrote:
>     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)
>             > [copy of
>          http://bazaar-vcs.org/bzr/bzr.dev/doc/developers/tortoise-strategy.txt]
>         [Peer] 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.
>     [Stefan] I'm not sure what exactly you want to improve here.
> After I have thought some more about it I realise that it is probably 
> NOT a good idea to try to build a generalized stub.
> The analysis by Mark Hammond indicates that script-based tortoises (TBZR 
> and THG) will get version conflicts and bloated memory usage. The 
> proposed solution is a small C++ client that calls a server application 
> (in Python).
> As you have explained, TSVN has a similar structure, but for different 
> reasons. The client TortoiseStub allows you to select which of three 
> modes to use (cache/shell/none), and the server TortoiseCache can crawl 
> the file system to give faster display of overlay icons.

The TortoiseStub is not to select which mode to use but only to prevent 
apps other than explorer.exe from loading the extension dlls. The mode 
'switch' is done in the TortoiseSVN dll.

> It makes sense for TBZR and THG to share code for the tortoise stub (the 
> client), but why should any other tortoises want a common code base?
> The consequence would be
> (1) wider audience means that tortoisestub would be tested more.
> (2) complexity increases by generalizing TSVN stub instead of forking it.
> The first is void for TSVN as they have a large audience, and the code 
> has been tested for a while. Refactoring the code would only destabilize 
> it. The latter is an argument against common code.
> Conclusion: TBZR and THG should do their own stub, probably by forking 
> TSVN code.

I'm still not quite sure what code exactly you want to share between the 
Tortoise clients. Calling the status process would definitely not work, 
since it would not only be the status that's cached (at least TSVN 
caches a lot more info than just the status - in fact it caches all 
information that is available from the working copy). So if you would 
want to share that code, you'd have to either get a list of information 
that all Tortoise clients could cache - which means a *lot* of overhead 
since I doubt that the different versioning systems have a lot of that 
information in common.


   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/20080421/eb02682a/attachment-0275.pgp 

More information about the bazaar mailing list