[msysGit] Re: [Tortoisehg-discuss] Bazzar stratgy regarding shell extension

[Stefan Küng]

Mark Hammond wrote:

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?

Some reasons why people don't like the cache:

* it needs memory. People who rarely use version control don't like that and switch back to 'shell' or 'none' (TSVN settings which don't use the cache) * the cache is by definition always out-of-date. But it monitors the file system for changes and when it detects such changes it re-crawls the corresponding working copy to fetch the status again. Since the re-crawling also happens at times the users don't really want it to (i.e., they don't care about the accuracy of the overlays at that time), they also turn off the cache. * re-crawling a very big working copy means a lot of disk access. So users who have such big (> 5GB) working copies also turn off the cache sometimes.

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 :)

But I think the 'little' source control work they do is *very* specific. :)

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.

But you won't gain anything by having a common context menu provider. Menu items are not limited like the overlay slots, the commands are different (push vs. commit, update vs. pull, ...), ... And: TSVN fetches the status in the context menu directly, i.e., it does *not* use the cache. Depending on the status, the menu entries are shown (i.e., only entries that make sense for a given status are shown). The reason why the cache is not used for the context menu is that (as mentioned above) the cache is always out-of-date (usually only by a few seconds, which is fine for overlays), and that's not acceptable for a context menu.

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.

Yes, the column providers are no longer supported on Vista. I still hope that MS will see that they did a stupid thing by abandoning those and re-introduce them in the next Windows version. Or at least some other means to show properties for *all* filetypes and not just specific ones.

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.

Stefan

--
       ___
  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.net

I'm still missing details here. You say you want to share some code between the different Tortoises. But what parts exactly? What *can* be shared, what's common in fetching the status/showing context menus between the different SCMs? It won't help if we can come up with some common code, but that code has lots of switch/case of if statements in it to differ between the different Tortoise implementations. I don't say it isn't possible to come up with something that can be shared, but I still think it's not worth the effort - we won't really gain anything by doing it.

signature.asc
Description: OpenPGP digital signature