RE: [TSVN] RFC: New cache scheme

Will Dean wrote:
> At 09:56 21/01/2005 +0000, you wrote:
>
>> This would be misleading - I can imagine what would happen if
>> tsvncache became unavailable (for whatever reason and my wc was all
>> marked unversioned - you're asking for a potentially large number of
>> 'bug' reports here.
>
> 'Marked unversioned' was just my confusing way of saying 'doesn't get
> an overlay'
OK, but it will still be/look *wrong* to people.

> Anyway, if the cache has become unavailable, then that *is* a
> bug, so a bug report doesn't seem out of place...
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.
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?
Just being able to switch it off, and/or mark some folders with a
TSVNcacheIgnoreThisFolder property might be useful to some people.

>> If you do what Toby suggests and have tsvncache settings tab you can
>> also fail gracefully if the cache is not present - if the cache is
>> stopped or doesn't respond to it's ipc calls then you stop trying to
>> use it and set the status of objects the slow but reliable way.
>
> That would involve the shell extension having all the SVN
> status code in it
> again though, which would be a pity.
Not all of it - you wouldn't need the bits to do with caching...
 
> My only point about surviving cache process stops and starts
> was not that
> it's got any particular relevance to normal use, just that it makes
> development of the caching software *enormously* easier than
> with the shell extension.
Agreed, I was just trying to suggest building in some extra robustness up
front.

> 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?
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.

Sounds like it could be good, if the problems Stefan mentioned can be
overcome.
Thanks for the good work,
Bill

-- 
       ___
  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.tigris.org
This e-mail transmission is strictly confidential and intended solely
for the person or organisation to whom it is addressed. It may contain
privileged and confidential information and if you are not the intended
recipient, you must not copy, distribute or take any action in reliance
on it. If you have received this email in error, please reply to the
sender as soon as possible and delete the message. Please note that we
are able to, and reserve the right to, monitor e-mail communications
passing through our network.
The views expressed in this email are not that of the company unless
specified within the message.
The inclusion of this footnote indicates that the mail message and any
attachments have been checked for the presence of known viruses.
If you have any comments regarding our policy please direct them to
postmaster@cox.co.uk
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org