Mark Hammond wrote:
> Hi all,
> First up, congratulations on the success and quality of your project - it
> has been a pleasure to dig into various parts of it recently!
>
> I'm working with the 'bazaar' source control project on updating the
> 'tortiose-bzr' extensions. To cut a long story short - bazaar (and
> incidentally Mercurial) are both implemented in Python, but it is
> undesirable to have our shell extensions load Python into every process that
> makes use of the shell. This means that our shell extensions can't directly
> make use of the VCS library - it must do so only via external processes.
> For more detail, please see
> http://bazaar-vcs.org/bzr/bzr.dev/doc/developers/tortoise-strategy.txt
>
> In practice, this means we will implement the shell extension in C++ and use
> an external process very similar to TSVNCache to manage caching and
> interactions with the underlying VCS. There are 2 major implications here
> though:
>
> * We *insist* on the cache process running externally (and if I read the
> sources correctly, the TSVN cache currently falls back to an in-process
> model in some cases - but I think even with Vista/rdesktop we can arrange
> for a useful process to exist in those cases)
Yes, TSVN falls back to fetch the status directly from the shell
extension if the overlay setting is set to 'shell' instead of 'default'.
But that has nothing to do with the cache process: if set to 'shell',
the cache process is terminated.
> * All VCS commands go via the cache process. *Everything* needed to
> determine the icon overlay etc for every item must come via the external
> process.
>
> So my first question is: does this approach sound reasonable?
Yes.
> Assuming it does, it strikes me that we need something very very similar to
> TSVNCache - and TSVNCache already has a stable implementation with many edge
> cases handled well. Indeed, relatively little of the TSVNCache source code
> seems related to talking to subversion, but is instead a fairly generic
> implementation. So I'm wondering if you guys have any interest in, or
> thoughts about how we could extend TSVNCache to cleanly separate out the VCS
> specific code so it is more suitable for reuse? It might also prove useful
> for Mercurial in the future, which finds itself in a similar position.
Since I have no idea on how bazaar handles the status of files and
folders, I can't really say whether you could use some part of the
TSVNCache source. It is optimized to handle the Subversion situation of
fetching the status:
1) fetching the status for a single file/folder is takes (almost) as
long and as many disk accesses as fetching the status for all items
inside one folder.
2) that's why TSVNCache only fetches the status for whole folders, even
if the shell only asks for the status of one file (which it always does).
3) all folders are completely independent of each other. The cache
doesn't know what a "working copy" is, only whether a folder is
versioned or not. It does *not* know whether one folder belongs to the
same working copy as another.
4) the edge cases you mentioned above are mostly Subversion specific
(how Subversion fetches the status, how it priorities the status, ...)
> I'm obviously willing to do as much of that as I can if we agree on a
> general approach, so I'd love to hear your thoughts...
If you want one cache process which can handle different version control
systems, you first need to do some ground work:
* how should the cache process call the different VCS status functions?
* how should it determine and store the different status informations (I
doubt that bazaar has the same information as Subversion)
* how would you handle loading two different Python runtimes in case
bazaar and Mercurial won't use the same version? AFAIK you can't load
two different Python runtimes into the same process, so how would that
situation be handled?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Received on 2008-04-30 22:37:32 CEST