bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#20637: incompatible, undocumented change to vc-working-revision


From: Dmitry Gutov
Subject: bug#20637: incompatible, undocumented change to vc-working-revision
Date: Wed, 13 Apr 2016 23:49:12 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0

Hey Michael,

On 04/13/2016 06:14 PM, Michael Albinus wrote:

vc-working-revision shall return nil for unregistered files. vc-state
shall return a non-nil value, 'unregistered.

That sounds fine to me in principle, but I don't think we can get there for Emacs 25.1, without paying with lower performance (*). The current code is slower than what's in 24.5 already, as a result of the aforementioned revision.

You cannot guarantee this. Anybody is free to call the functions with
unregistered files.And in the vc-state case, it is even documented that
this could happen.

Both true. However, that vc-state's behavior has been different from its documentation in this regard, for many releases.

In particular, it breaks an assumption I made when fixing #11757, that
vc-git-state never receives an unregistered file as input. So if you
evaluate (vc-state "1") now, it'll return `up-to-date'.

This assumption could be kept if vc-state filters such unregistered
files out.

Problem: vc-registered is slower than vc-backend. Like, orders of magnitude slower. vc-backend caches the result of the previous vc-registered invocation in vc-file-prop-obarray. But if we call vc-registered directly, we go the whole way each time, including calling vc-BACKEND-registered.

Yes, both vc-state and vc-working-revision cache their results in a property, so we're only paying the added overhead when the file is opened, reverted, etc, but it's still a price. Don't you think it is a problem?

I've prepared a patch which just covers the case that a file is
unregistered, in both vc-state and vc-working-revision. It is a very
small change, that I believe it could still go into the emacs-25 branch.

Aside from the above, is there a reason to keep using vc-responsible-backend instead of vc-backend, in vc-state and vc-working-revision? It's also slower than vc-backend.

(*) If you _really_ think that vc-state should ever return `unregistered' (personally, I've never found that distinction useful; we could just as well update the docstring that it returns nil in that case), I think the way to get that is to make vc-git-registered return non-nil for all files inside Git-controlled repositories, and to make vc-git-state return `unregistered' for unregistered files (and same for other backends). But it would be a bigger change, better suitable for the next release.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]