John Arbash Meinel wrote:
You missed my point entirely.
I don't think so :)
What you gain is a *shared* cache. So that you can allow up to XX
You mean a shared process. The cached information *can not* be shared because it's not the same information!
megabytes of memory in your cache. And if TSVN is very active, it will be able to use the whole cache. If both TBZR and TSVN are active, then they will share the cache. If TBZR is not doing anything, then it doesn't have to reserve any of the space in the cache. If you didn't have a shared cache, then each process would need to be more conservative as to how much it can cache, since it doesn't know how much is being cached by the other processes. I would actually estimate that you would save very little based on paths. Just because you are unlikely to have the same path in both SVN and BZR/HG/etc. If you did, I'm not sure what the programs would do anyway. (How do you show that the status is committed in SVN, but modified for BZR?) It isn't about saving memory, it is about *sharing* memory.
Ever heard of the term "operating system"? One of the jobs such an operating system has is to manage the memory between processes. I'm sorry, but sharing a cache for what you describe is *not* what we should do. It's the job of the OS to manage the memory, not the job of a shared cache process. Or have you ever seen something like this? Ever seen graphic editor share the memory?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
signature.asc
Description: OpenPGP digital signature
