|
From: | Dmitry Gutov |
Subject: | bug#11757: Acknowledgement (24.1.50; vc-git calls `process-file' too many times) |
Date: | Wed, 04 Jul 2012 20:42:40 +0400 |
User-agent: | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 |
On 04.07.2012 19:10, Michael Albinus wrote:
Was the file absent in the branch test after checkout? If not, this case is no different from the first. Basically, we need a scenario in which `vc-next-action' will need to call `vc-git-register' on a file that recently has been considered up-to-date.If we assume, any command outside Emacs can happen which invalidates the cached status of a file, we must clear all caches and recompute all files state when vc-next-action is called. To the given cost.
I'd have no problem with this, actually - this function is called considerably less often than `find-file' or `save-buffer'.
In Tramp, I have similar problems with stale caches. Finally, I've added timestamps to every cached value, and I use cheap tests to check whether the cache is out of date. No idea, whether we want go this direction in vc, too.
Can't commend on that.
If we assume that there are no dangerous vc commands outside Emacs, we wouldn't have a problem.
In this case, the behavior of the first patch I posted here should be acceptable, right? It's simpler, has pretty much the same effect, and should be a tiny bit faster.
The logic is rather complicated there, so I might easily be missing some examples.Yes. I don't know, whether we will be able to handle any surprise when using caches. There will always be a scenario which lets fail a given algorithm. I fear.
Sure, but I'm just asking for one scenario that works better with explicitly caching 'git-registered, instead of not calling it in `vc-git-state'. If `vc-git-state' doesn't call `vc-git-registered' (just assumes it's t), then `vc-registered' is the latter's only client, and so its return value is implicitly cached in 'vc-backend property.
[Prev in Thread] | Current Thread | [Next in Thread] |