On Sun, Apr 20, 2008 at 11:15 PM, Peer Sommerlund
<peer.sommerlund_at_gmail.com> wrote:
>
>
> On 19/04/2008, Stefan Küng <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).
I probably should try to read into Mark Hammond's proposal as close as
you have, anyway...
To me, by far the biggest problem with TortoiseHG now is the _speed_
in displaying the overlay icons. I don't worry that much about the
memory footprint just yet, as long as we can contain any potential
memory leak. Someone is going to eat RAM. It's either the RPC server,
or Explorer itself.
Without a asynchronous mechanism in overlay extension, the delay will
always be there, as someone is going to have to wait for the status
checking to return. Though TSVN got around this with the caching
server.
Having said that, I'm sure there are a lot of really smart people out there.
> 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.
>
> 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.
>
>
> My apologies for wasting your time,
> Peer
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Tortoisehg-discuss mailing list
> Tortoisehg-discuss_at_lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
>
>
Received on 2008-04-22 07:51:01 CEST