GNU bug report logs - #20637
incompatible, undocumented change to vc-working-revision

Previous Next

Full log

Message #43 received at 20637 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Glenn Morris <rgm <at> gnu.org>, 20637 <at> debbugs.gnu.org
Subject: Re: bug#20637: incompatible, undocumented change to
 vc-working-revision
Date: Wed, 13 Apr 2016 23:49:12 +0300

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.