[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Thu, 01 May 2008 17:08:09 +0200

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.

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.

Stefan

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

Received on 2008-05-01 16:08:38 CEST

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.