[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: |
Sat, 9 Apr 2016 23:42:50 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 |
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.
- bug#20637: incompatible, undocumented change to vc-working-revision, Michael Albinus, 2016/04/09
- bug#20637: incompatible, undocumented change to vc-working-revision,
Dmitry Gutov <=
- bug#20637: incompatible, undocumented change to vc-working-revision, Michael Albinus, 2016/04/10
- bug#20637: incompatible, undocumented change to vc-working-revision, Dmitry Gutov, 2016/04/10
- bug#20637: incompatible, undocumented change to vc-working-revision, Michael Albinus, 2016/04/10
- bug#20637: incompatible, undocumented change to vc-working-revision, Dmitry Gutov, 2016/04/10
- bug#20637: incompatible, undocumented change to vc-working-revision, Michael Albinus, 2016/04/11
- bug#20637: incompatible, undocumented change to vc-working-revision, Dmitry Gutov, 2016/04/13
- bug#20637: incompatible, undocumented change to vc-working-revision, Michael Albinus, 2016/04/14
- bug#20637: incompatible, undocumented change to vc-working-revision, Dmitry Gutov, 2016/04/14
- bug#20637: incompatible, undocumented change to vc-working-revision, Michael Albinus, 2016/04/14
- bug#20637: incompatible, undocumented change to vc-working-revision, Dmitry Gutov, 2016/04/14