Hi Stefan,
> Nice document. But next time, before you just assume things about TSVN
> could you please ask me first?
That is my document and my fault - my apologies for not contacting you
earlier.
> "As soon as the FileOpen dialog is loaded, TortoiseSvn loads well over
> 20 additional DLLs, including the MSVC8 runtime, into the Notepad
> process causing its memory usage to more than double - all without
> doing
> anything tortoise specific at all."
>
> But that doesn't mean that Windows will use double the memory. Those
> dlls are already in memory, and Notepad will use those already loaded
> dlls. Yes, the task manager shows an increased amount of memory for the
> process, but it doesn't mean that more RAM is actually used.
Yes, I should have qualified my statements. But code will be executed by
loading these DLLs and my statement was made more in the context of shell
extensions generally than trying to pick on TSVN - in other words, that
statement is more about justification for *not* using Python, using TSVN as
an example that was easy to quantify.
> Also, TSVN has an option (also in the settings dialog) to enable the
> overlays and all other stuff "only in explorer". If that option is
> activated, then TSVN will *not* load all the extension dlls for other
> processes using the file-open dialog. We have a really, really small
> dll
> to acomplish that (project "TortoiseStub" in our source tree).
Yes, I saw that, but I doubt we will provide such an option for TBZR in the
early days. I'm also slightly concerned that with the new APIs and objects
exposed by Vista making it much easier to reuse Explorer in your own process
(ie, CLSID_ExplorerBrowser etc) it will slowly make less sense.
> The reason that the shell extension dll also has the ability to fetch
> the Subversion status directly is simply because of the "shell" setting
> for the overlays: some people don't like the cache.
Do you know what they don't like about the cache? Does it get out-of-date?
I'm also interested to know how recursive directory status is handled
without the cache?
> But since the svn
> library is written in plain C, that's not a problem.
Not trying to be pedantic, but the issue is more about what other libraries
are used by the C code. I agree that subversion's library is light enough
(in terms of external deps) for this to not be a problem though :)
> I'm not sure what exactly you want to improve here. You can't just use
> one shell extension dll for all Tortoise clients - they're made for
> different versioning tools and have very few things in common.
I'm not personally advocating any attempts to share binaries. However, I
have been struck by how little source-control work these extensions actually
do. I'm sure that is just because I'm not looking hard enough though :)
> For example, the context menu extension is different for every Tortoise
> client. The same for the column provider.
They seem quite similar to me. Indeed, many of the context menu operations
don't do much more than build and execute a command-line based on the
filename(s) selected. Eg, I'd estimate that only ~10-15% of
ContextMenu.cpp[1] relates directly to subversion, and even that code is
generally limited to getting an integer based "status" for a particular
item.
[1]
http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/src/TortoiseShell/Contex
tMenu.cpp
Column providers seem similarly generic and could be implemented given some
way to fetch "properties" by arbitrary name or ID. OTOH, Column Providers
appear dead moving forward, so I doubt we will expend much energy on them.
> If you want to have some common status-fetching process, that wouldn't
> work either: different version control systems have different status
> and also work completely different.
I think we can still do things at a higher level. Consider the Icon Overlay
handling - so long as we consider the operation in terms of the shell (ie,
what icon overlay should be used for an item) instead of in VCS terms, it
should be easier. The code that is VCS specific must then also know
intimate details about Tortoise (ie, it must know how to map its concept of
status to shell extension concepts such as overlay index) but that sounds
reasonable. As mentioned, I'm only currently interested in source-code
sharing, not sharing binaries.
I'm confident you will tell me that the devil is in the detail though - so
anything you can do to educate me is appreciated.
Also, my apologies for missing this thread before posting a new thread on
the tortoisesvn dev list - I've just returned from 2 weeks off, and although
I skimmed the bzr list, a closer look revealed it! Thanks for your reply to
that thread and I will follow up once I've spent a little more time
validating my ideas and coming up with concrete examples.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_tortoisesvn.tigris.org
For additional commands, e-mail: dev-help_at_tortoisesvn.tigris.org
Received on 2008-05-01 03:41:50 CEST