Will Dean wrote:
> 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!
If the user notices - if a file has the wrong overlays with no warning it
might shake one's faith in tsvn - mind you the flakiest part always seemed
to be the icon overlays anyway.
>> 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.
No, that's not what I meant, I don't think a crash will be common either,
but the issue I raised was what to do if it does happen.
..snip..
> Personally, I don't think data memory consumption is a big deal here.
Probably not, I replied to Stefan's mail wrt this but I agree.
> 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.)
True, if it's fast enough no-one will worry. Not for local drives anyway...
>> 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.
I just meant if the cache crashed could tsvn struggle on with no cache but
still update the statuses? If that's not sane then fine, decision made, it's
just another thing to consider.
Btw I presume the user would be told?
>> 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.
Possibly, but if it was the same code included in both places...
never mind, it's fruitless to consider how to do something which isn't
wanted.
>> 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.
Or "Two good schemes are better than one"
or "A Scheme in the hand is worth two in the bush"...
> 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.
I didn't say it did - be able to update status without the cache was one way
to deal with a (probably rare) crash. To me 'designing for failure' means
looking at as many (reasonable) scenarios as possible and ways to deal with
them. Then you decide which ones are worth worrying about - in this case it
seems that the design has considered letting tsvn work without a cache and
decided not to do that, and that's fine.
I was trying to avoid the badly thought out bit, and just wanted to
investigate the desired behaviour of tsvn in cases of cache failure. Which I
think is what we've largely done.
..snip..
> 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.
Which begs the question of why it crashed in the first place and if it might
happen again.
IF it crashes, which it probably won't.
> 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!
Hmm, _if_ I had commit to the repo it could end up like a wikipaedia edit
war!
No, I'm happy enough with things the way they are, tsvn is one of the best
os projects I'm aware of, if you and Stefan agree on the design it's most
likely a good solution. If it's not I'm quite sure one/both of you would
change it anyway.
(And I don't have the tools here anyway.)
>> 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.
I was mostly thinking of the comments on FindFirstChangeNotification
slowness and traps with the recursive status fetching. I'm sure it'll all
get thrashed out though.
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
Received on Fri Jan 21 17:04:08 2005