More options for how caching is done

Bug #330761 reported by baxissimo on 2009-02-17
4
Affects Status Importance Assigned to Milestone
TortoiseBZR
Wishlist
Unassigned

Bug Description

The tbzrcachew application has the same problem as TortoiseSVN's cacher. Both of them interact poorly with removable devices. If you keep source code on a portable USB harddrive, the cacher holds on to references to files on the portable drive, preventing it from being removed safely.

In both TortoiseSVN and TortoiseBZR you can disable the icon overlays completely to work around the problem. But the problem is not the icons, its the cacher. The icons are very helpful.
So what they've done in TortoiseSVN is to provide a middle mode that caches in a different way that isn't quite as dynamic, but still lets you see the icons.

http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-settings.html
They call it "Shell" caching:

"""
Shell

    Caching is done directly inside the shell extension dll, but only for the currently visible folder. Each time you navigate to another folder, the status information is fetched again.

    Advantage: needs only very little memory (around 1 MB of RAM) and can show the status in real time.

    Disadvantage: Since only one folder is cached, the overlays don't show the status recursively. For big working copies, it can take more time to show a folder in explorer than with the default cache. Also the mime-type column is not available.
"""

And they don't mention it, but the other advantage is that it doesn't hold locks to files on the drive, preventing it from being removed.

Of course the ideal here would be to figure out how to make the tbzrcache operate without creating the long-lasting locks on files that prevent removing portable drives.

Mark Hammond (mhammond) wrote :

I'm hoping this will be less of an issue in the next build, as we watch for device removal attempts and release any handles we have on the device. Unfortunately this isn't enabled in the currently released versions and will lead to the problem you indicate (although we should still only hold the device open for a couple of minutes, so the device should become removable after that period even without stopping the cache process.)

On Wed, Feb 18, 2009 at 9:02 AM, Mark Hammond <email address hidden> wrote:
> I'm hoping this will be less of an issue in the next build, as we watch
> for device removal attempts and release any handles we have on the
> device. Unfortunately this isn't enabled in the currently released
> versions and will lead to the problem you indicate (although we should
> still only hold the device open for a couple of minutes, so the device
> should become removable after that period even without stopping the
> cache process.)

That sounds good. I hope the monitoring for removal attempts works.

Is there any connection between TortoiseBzr and TortioseSVN at all?
Because I would love to see the latter fixed, too. I tried to report
a bug to them but it didn't go well. Either I couldn't find the bug
tracker or I got no response, or I got a brush-off response. I don't
recall what it was but it wasn't nearly the smooth experience I had
reporting the issue here.

Mark Hammond (mhammond) wrote :

I had the same experiences with the tsvn team :(

The only connection is that much of tsvn was manually "ported" to Python - including the device removal notification code, so I'm surprised you have problems with that. tbzr has no option of 'in-process' caching at all - but I'm not clear why that would be necessary; in general, once a scan for the status of a tree is finished, the only handles we keep open are explicitly for detecting changes to the file-system so our cache can be invalidated and it is these handles we close on a device removal notification. As such, as "in-process" cache wouldn't actually solve anything - its not the fact we just scanned the directory that is a problem, it is that we are watching for subsequent changes. Either way, I'd recommend we wait for the next version, and if problems remain, the logs should give us some clues as to what they are...

baxissimo (wbaxter) wrote :

On Wed, Feb 18, 2009 at 3:49 PM, Mark Hammond <email address hidden> wrote:

> in general, once a
> scan for the status of a tree is finished, the only handles we keep open
> are explicitly for detecting changes to the file-system so our cache can
> be invalidated and it is these handles we close on a device removal
> notification.

Hmm. Maybe I was too impatient to get disconnected. It didn't take
to tries for me to jump to the conclusion that "this is the same old
problem as tortoise svn". And with tsvn waiting doesn't seem to help.

Changed in tortoisebzr:
importance: Undecided → Wishlist
INADA Naoki (songofacandy) wrote :

This problem still exists?

Changed in tortoisebzr:
status: New → Incomplete
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers