<div>On 21/04/2008, Stefan Küng <<a href="mailto:tortoisesvn@gmail.com">tortoisesvn@gmail.com</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Peer Sommerlund wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> On 19/04/2008, *Stefan Küng* <<a href="mailto:tortoisesvn@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">tortoisesvn@gmail.com</a> <mailto:<a href="mailto:tortoisesvn@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">tortoisesvn@gmail.com</a>>> 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                 <a href="http://bazaar-vcs.org/bzr/bzr.dev/doc/developers/tortoise-strategy.txt" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://bazaar-vcs.org/bzr/bzr.dev/doc/developers/tortoise-strategy.txt</a>]        [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. </blockquote> 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. <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> 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. </blockquote> 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. </blockquote></div> If I understand correctly, then the TSVN stub will decide runtime if the caller was windows explorer or not, and then load only the required libraries. Some of these lines of code would be the same for all tortoises. In Mark Hammond's proposal the python tortoises need to forward a call from a C++ client to a Python server. These few lines could probably be recycled without too much effort. My gut feeling is that the effort required to generalize the VCS specific data could be better used elsewhere. The VCS specific data would of course vary from tortoise to tortoise, but it is not impossible to parametrize this. It could be done with a structure similar to, but much simpler than, <a href="http://ADO.NET">ADO.NET</a> <a href="http://en.wikipedia.org/wiki/ADO.NET#DataSets">DataSet</a>. However, it would add complexity. As I understand the TSVN TortoiseCache, it contains a crawler and a cache. If the cache was storing parametrized data, it would be generic. For multiple-tortoise users the number of cache processes would be 1 instead of N, but the memory and cpu usage would be the same: For each repository the cache would store the data needed by that particular VCS. The number of users would be higher (since the code would be shared), thus the number of bugs found should be higher. This mostly benefits the smaller tortoises: Say TSVN and THG developed this code. TSVN 1.4.8 has been downloaded 700,000 times from sourceforge, where THG 0.3 was downloaded only 7,000 times. Regards, Peer