From: Michael Albinus <michael.albinus@gmx.de>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: 20637@debbugs.gnu.org
Subject: bug#20637: incompatible, undocumented change to vc-working-revision
Date: Sun, 10 Apr 2016 10:00:17 +0200 [thread overview]
Message-ID: <878u0llwq6.fsf@gmx.de> (raw)
In-Reply-To: <e1d43fd0-0aeb-74cd-70ab-3c7902ced002@yandex.ru> (Dmitry Gutov's message of "Sat, 9 Apr 2016 23:42:50 +0300")
Dmitry Gutov <dgutov@yandex.ru> writes:
> Hi Michael,
Hi Dmitry,
>> 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).
If there is a simple and obvious fix for this problem, let apply it to
the emacs-25 branch. Even if we must change it later in master.
But I doubt that's possible. This bug report was written on 23 May 2015,
it was marked as release blocker on the same day, and still no fix. I
believe that there won't be a fix in emacs-25, and whatever we might
find on our way to stabilize vc, it will be too late and too much to be
applied to the emacs-25 branch.
For all those problems in vc I have the impression, that we must
stabilize vc first. Starting with the very basic functionality - that's
why I've added tests for vc-backend and vc-responsible-backend. Often,
there might be not an error, but missing or wrong documentation. As
Glenn has said also in bug#19548, another release blocker for 25.1.
I don't care whether we discuss it here, in bug#19548 or in the
emacs-devel ML. But at least *I* am not able to handle those issues
differently. And nobody but you and me seem to work on vc problems in
general.
>> 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.
As said, I doubt that we will find something which could go into
emacs-25. Of course I would be happy if I'm wrong :-)
>> 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.
The docstring says nothing about directories, so the call I've applied
is legal. If vc-backend is not intended for directories we should
document it first. But ...
> For directories, one has to call vc-responsible-backend.
... I even doubt that directories are out of scope of vc-backend.
Directories can be registered for some VCS, for example for CVS, or for
ClearCase which I use at work (I know, we have no official support for
ClearCase in vc). Therefore we shall precise the docstring of
vc-backend, that it returns the backend also for directories for VCSes
which support rgistration of directories.
A pointer to vc-responsible-backend might also be helpful in the
docstring of vc-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.
I know what the docstring says :-) My question is, whether we shall
offer the same argument list for both vc-backend and vc-responsible-backend.
>> - 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?
Don't know. But I believe "interactively" is not the criterion whether a
general vc function shall exist. I also don't call vc-registered 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?
Yes. And I'm still in favor of adding vc-unregister in vc.el.
Best regards, Michael.
next prev parent reply other threads:[~2016-04-10 8:00 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-23 23:49 bug#20637: incompatible, undocumented change to vc-working-revision Glenn Morris
2016-03-28 23:28 ` Dmitry Gutov
2016-03-29 18:13 ` Michael Albinus
2016-04-01 0:36 ` Dmitry Gutov
2016-04-09 19:34 ` Michael Albinus
2016-04-09 20:42 ` Dmitry Gutov
2016-04-10 8:00 ` Michael Albinus [this message]
2016-04-10 16:00 ` Dmitry Gutov
2016-04-10 18:09 ` Michael Albinus
2016-04-10 18:58 ` Dmitry Gutov
2016-04-11 6:55 ` Michael Albinus
2016-04-13 20:55 ` Dmitry Gutov
2016-04-14 7:10 ` Michael Albinus
2016-04-14 13:53 ` Dmitry Gutov
2016-04-14 15:26 ` Michael Albinus
2016-04-15 0:33 ` Dmitry Gutov
2016-04-15 13:13 ` Michael Albinus
2016-04-14 15:23 ` Eli Zaretskii
2016-04-13 15:14 ` Michael Albinus
2016-04-13 20:49 ` Dmitry Gutov
2016-04-14 7:21 ` Michael Albinus
2016-04-14 14:20 ` Dmitry Gutov
2016-04-14 18:31 ` Michael Albinus
2016-04-15 0:20 ` Dmitry Gutov
2016-04-15 13:11 ` Michael Albinus
2016-04-17 0:44 ` Dmitry Gutov
2016-04-18 12:27 ` Michael Albinus
2016-04-18 12:33 ` Dmitry Gutov
2016-04-18 12:46 ` Michael Albinus
2016-04-18 1:40 ` Dmitry Gutov
2016-04-15 1:01 ` Dmitry Gutov
2016-04-15 1:04 ` Dmitry Gutov
2016-04-15 13:23 ` Michael Albinus
2016-04-17 0:17 ` Docstrings and manuals, was: " Dmitry Gutov
2016-04-17 8:49 ` Docstrings and manuals Michael Albinus
2016-04-17 10:50 ` Dmitry Gutov
2016-04-17 11:16 ` Michael Albinus
2016-04-17 11:42 ` Dmitry Gutov
2016-04-17 12:19 ` Michael Albinus
2016-04-17 13:12 ` Dmitry Gutov
2016-04-17 15:14 ` Eli Zaretskii
2016-04-17 16:39 ` Michael Albinus
2016-04-17 19:39 ` Dmitry Gutov
2016-04-17 15:12 ` Eli Zaretskii
2016-04-17 19:59 ` Dmitry Gutov
2016-04-18 2:30 ` Eli Zaretskii
2016-04-18 12:55 ` Phillip Lord
2016-04-18 15:35 ` Marcin Borkowski
2016-04-18 15:47 ` Stefan Monnier
2016-04-18 16:30 ` Marcin Borkowski
2016-04-18 18:56 ` Eli Zaretskii
2016-04-18 19:33 ` Stefan Monnier
2016-04-18 19:39 ` Eli Zaretskii
[not found] ` <<83ziss9sml.fsf@gnu.org>
2016-04-17 15:54 ` Drew Adams
2016-04-17 15:03 ` Eli Zaretskii
2016-04-17 15:15 ` Dmitry Gutov
2016-04-17 16:23 ` Eli Zaretskii
2016-04-17 20:22 ` Dmitry Gutov
2016-04-18 2:33 ` Eli Zaretskii
2016-04-18 8:38 ` Richard Stallman
2016-04-18 9:50 ` Dmitry Gutov
2016-04-19 0:25 ` Richard Stallman
2016-04-19 7:59 ` Dmitry Gutov
2016-04-19 23:51 ` Richard Stallman
2016-04-17 0:27 ` bug#20637: incompatible, undocumented change to vc-working-revision Dmitry Gutov
2016-04-18 1:33 ` Dmitry Gutov
2016-04-18 12:28 ` Michael Albinus
2016-04-18 12:37 ` Dmitry Gutov
2016-04-18 12:53 ` Michael Albinus
2016-04-18 12:58 ` Dmitry Gutov
2016-04-18 13:06 ` Michael Albinus
2016-04-18 16:34 ` John Wiegley
2016-04-18 14:55 ` vc-state and unregistered (was: bug#20637: incompatible, undocumented change to vc-working-revision) Michael Albinus
2016-04-18 21:11 ` vc-state and unregistered Dmitry Gutov
2016-04-19 8:10 ` Michael Albinus
2016-04-19 8:21 ` Dmitry Gutov
2016-04-19 8:31 ` Michael Albinus
2016-04-19 8:43 ` Dmitry Gutov
2016-04-24 12:11 ` Michael Albinus
2016-04-24 12:21 ` Dmitry Gutov
2016-04-24 12:45 ` Michael Albinus
2016-04-24 12:49 ` Dmitry Gutov
2016-04-24 13:07 ` Michael Albinus
2016-04-24 13:13 ` Dmitry Gutov
2016-04-24 13:24 ` Michael Albinus
2016-04-24 13:27 ` Dmitry Gutov
2016-04-24 14:03 ` Michael Albinus
2016-04-24 17:23 ` Dmitry Gutov
2016-04-24 17:35 ` Dmitry Gutov
2016-04-24 18:13 ` Michael Albinus
2016-04-24 18:58 ` Dmitry Gutov
2016-04-24 19:41 ` Michael Albinus
2016-04-24 20:43 ` Dmitry Gutov
2016-04-24 13:08 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878u0llwq6.fsf@gmx.de \
--to=michael.albinus@gmx.de \
--cc=20637@debbugs.gnu.org \
--cc=dgutov@yandex.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.