At 10:28 21/01/2005 +0000, you wrote:
>OK, but it will still be/look *wrong* to people.
Yes, but it will *BE* wrong, so I don't have a problem with this!
>Fair enough if the cache is being used - you can always bring up a dialog
>reporting that the cache has crashed, with any debug info you think might
>help in a bug report.
I don't think we should expect the new cache to crash more because it's in
a separate process than we do with the existing cache, which is built into
the shell extension. You've made me realise that linking with the
crash-reporter DLL is a good idea, but I don't think we need to think of
crashes as something which is going to be a normal occurrance.
The shell extension will attempt to start the cache process if it needs it,
anyway.
>The other point is that this assumes that the cache is always going to be
>used, shouldn't it be configurable though - what happens to users with a
>huge wc, how much memory is it to grab?
Not very much, I don't think. But it depends how huge is huge. The files
are stored by directory, with just the filename part retained. The full
directory names are stored.
Lets say that a filename is on average 10 chars (20 bytes in unicode), and
that per file there's another 40 bytes of status info stored. Even for
100000 files, that's only 8Meg.
Then of course we've got some extra storage for the directory names,
allocation overhead, etc.
Personally, I don't think data memory consumption is a big deal here.
But for people with small machines and vast WC's, there will always be the
option to turn recursive caching off and shorten the lifetime of
objects. (We can have a garbage collector that runs through the cache and
discards old stuff.)
>Just being able to switch it off, and/or mark some folders with a
>TSVNcacheIgnoreThisFolder property might be useful to some people.
It might, but like all these things, we must decide if there's a real
problem to fix before we add lots of knobs and buttons. (There is already
a mechanism to tell TSVN to ignore or include various things for overlays
- we would continue to support all of this, though if the cache performance
was much better, people might be less worried about what was included and
what wasn't.)
>Not all of it - you wouldn't need the bits to do with caching...
I think all we're doing is turning the bug report which says 'the icons
overlays have disappeared', which could have some quite simple steps to
check what the cache is doing, into one which says 'explorer has ground to
a halt with the disk thrashing'. I'm not convinced that the latter is
easier to support than the former.
The current cache isn't anything to do with SVN, so with or without the
cache in the shell extension, we would still need all the SVN client library.
>Agreed, I was just trying to suggest building in some extra robustness up
>front.
Sure. I think that good cache process auto-restart behaviour is essential.
> > I don't see any particular reason to think that it would be
> > less reliable than what's happening at the moment.
>Agreed again, but why not plan for it anyway?
1. It would be nice to take the SVN client libraries out of the shell
extension.
2. Backup SVN status code which rots unused in the shell extension is
likely to have bugs and subtle problems which are not found in normal use.
>Version control is one of those really sensitive areas where I think people
>are more paranoid than in other areas - if you're editor crashes
>occasionally you can revert the file to the previous rev, if your VC
>software is even thought to be _possibly_ slightly unreliable you tend to go
>elsewhere.
>Design for failure, build to succeed.
I don't find that aphorisms like that contain much wisdom. I believe that
one good status fetching scheme is better than two mediocre ones. It is
frequently the case that badly thought-out 'redundancy' reduces total
system reliability. 'Designing for failure' doesn't mean arbitrarily
doubling-up parts of the code.
The current mode of failure of the SVN status system is to crash whatever
process you're running in (Explorer or whatever app's just done a file-open
dialog.) It's believed that at least some of these crashes come from bugs
in the SVN libraries (to the extent that Stefan wrapped them in exception
handling blocks.)
Removing the SVN client libraries from the shell extension removes this
crashing issue. If the TSVNCache process crashed, you'd suffer no
interruption to workflow at all, and the shell extension would just restart
it next time it needed some status info.
Of course, as an open-source project, you'd be entirely welcome to add the
SVN client code back to the shell extension if I removed it!
>Sounds like it could be good, if the problems Stefan mentioned can be
>overcome.
Blimey, I've missed those. Better go and have another look at his postings.
>Thanks for the good work,
No probs. Thanks for the useful suggestion.
Will
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Fri Jan 21 12:30:53 2005