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).
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
Received on 2008-04-22 10:10:14 CEST