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

Previous Next

Package: emacs;

Reported by: Glenn Morris <rgm <at> gnu.org>

Date: Sat, 23 May 2015 23:50:03 UTC

Owned by: Dmitry Gutov <dgutov <at> yandex.ru>

Severity: normal

Found in version 25.0.50

Fixed in version 25.1

Done: Michael Albinus <michael.albinus <at> gmx.de>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

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: bug#20637: incompatible, undocumented change to vc-working-revision
Date: Sat, 9 Apr 2016 23:42:50 +0300
Hi Michael,

On 04/09/2016 10:34 PM, Michael Albinus wrote:

> you have written several things I would like to move for later
> discussion. I believe, we shall start again from the basics.

OK, but the questions seem tangential to this bug report, which is a 
blocker for 25.1 (whereas investigating how various commands should 
work, isn't).

> I have extended vc-test-*01-register tests by calls to vc-backend and
> vc-responsible-backend. Mainly in order to understand how they work, but
> also for covering these functions. One problem I've found is that
> vc-file-*prop functions do not work well for relative file names; I've
> fixed this.

The change looks good, but nevertheless seeing the commit 5e1c32e in 
master makes me worried about conflicts when merging the necessary 
future fix for this bug from emacs-25 to master.

> Several problems I have marked with FIXME in the working horse of those
> tests, vc-test--register:
>
> - For some backends (CVS, RCS and SVN), vc-backend returns the backend
>   name for the newly created repo directory, and the directory is
>   registered already. For the other backends, vc-backend returns nil as
>   expected. Shouldn't this be consistent for all backends?

I'm not quite clear on what you are saying here. If you're calling 
vc-backend on a directory, I believe the result is undefined. As in, the 
function is allowed to return any value. Maybe we could check 
file-directory-p in vc-backend, and signal an error if it is.

For directories, one has to call vc-responsible-backend.

> - vc-backend accepts also a list of files, vc-responsible-backend
>   doesn't. Is this right?

I suppose. The function signatures say so. But I don't see any callers 
of vc-backend that actually pass a list to it.

> - There is no common function vc-unregister, just some backend specific
>   vc-<backend>-unregister.

Those are the implementations of the `unregister' backend command. It's 
only used in vc-transfer-file currently.

> Shouldn't vc-unregister exist?

Maybe it should. Would you ever use it interactively?

> It should call
>   common code, like vc-file-clearprops. For the time being, I have
>   emulated this.

Are you doing that just to test the `unregister' implementations?

Because otherwise, to clean up after a test, you can simply delete the 
directory with the test repository.




This bug report was last modified 9 years and 38 days ago.

Previous Next


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