From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.bugs Subject: bug#20637: incompatible, undocumented change to vc-working-revision Date: Sun, 10 Apr 2016 10:00:17 +0200 Message-ID: <878u0llwq6.fsf@gmx.de> References: <6ok2vyzwf9.fsf@fencepost.gnu.org> <08f70cda-44be-0657-e50a-2b2c80d2c21c@yandex.ru> <87mvphnoei.fsf@gmx.de> <874mbawp84.fsf@gmx.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1460275311 9314 80.91.229.3 (10 Apr 2016 08:01:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 10 Apr 2016 08:01:51 +0000 (UTC) Cc: 20637@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Apr 10 10:01:46 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1apAJV-0008EU-Lp for geb-bug-gnu-emacs@m.gmane.org; Sun, 10 Apr 2016 10:01:45 +0200 Original-Received: from localhost ([::1]:34128 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apAJU-0000lQ-VR for geb-bug-gnu-emacs@m.gmane.org; Sun, 10 Apr 2016 04:01:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34129) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apAIs-0007xk-6l for bug-gnu-emacs@gnu.org; Sun, 10 Apr 2016 04:01:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1apAIp-0004wX-0J for bug-gnu-emacs@gnu.org; Sun, 10 Apr 2016 04:01:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44200) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apAIo-0004wS-T0 for bug-gnu-emacs@gnu.org; Sun, 10 Apr 2016 04:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1apAIo-0000Iv-A3; Sun, 10 Apr 2016 04:01:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, Dmitry Gutov Resent-Date: Sun, 10 Apr 2016 08:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20637 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20637-submit@debbugs.gnu.org id=B20637.14602752271121 (code B ref 20637); Sun, 10 Apr 2016 08:01:02 +0000 Original-Received: (at 20637) by debbugs.gnu.org; 10 Apr 2016 08:00:27 +0000 Original-Received: from localhost ([127.0.0.1]:56536 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1apAIE-0000I1-Vc for submit@debbugs.gnu.org; Sun, 10 Apr 2016 04:00:27 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:59876) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1apAID-0000Hp-PN for 20637@debbugs.gnu.org; Sun, 10 Apr 2016 04:00:26 -0400 Original-Received: from detlef.gmx.de ([87.146.53.247]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LgI0W-1bcr7X23Vs-00nfpB; Sun, 10 Apr 2016 10:00:19 +0200 In-Reply-To: (Dmitry Gutov's message of "Sat, 9 Apr 2016 23:42:50 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-Provags-ID: V03:K0:/fYOp/YuKx8s6bmohfs6/V5S0PWh/bN0L1pG0Tj5tZpevcOerLE XeXH/3iV86KwRMNO9Z5Pjz03lYBg3VmYHoft7F+Z31G6Nizk4nntQRQCrCaUt3NshPeAxFk Y4PeJF93YZP8vj2Tw5uuiVb1FqJ751Oia+CB7X5qjCwh3ZDtsU7jKkfIoQWuPqf4Nx7O+Uc vw3rSVC4xoAv3LPe0BRsw== X-UI-Out-Filterresults: notjunk:1;V01:K0:M/6lLay+CYc=:2SvIPE6LsSy39pOmH56USg b1POfkCxgy4h+qvfG9Av4hMf8petWRV4i9eNXPfgM/isxX+fhP/21jP/5CO31kcjaRyq1q3+2 hW9e/nEcusMfr9bXV5rX5ENHfGBLpYlK44rLmnz3sbDQrKVUnNrPeZRoPYfiJ7hMOGa43KE68 3Ck/ynlIdEFlNgpHGPrk9okso4fW1YACvbne3pKkKJo7XkECtyeC2rXRBozh4LxF6p0qo9d6x pRKJ+qCDTm3T0WaNebziekuN/4OscIMRAe8g4x9gJpi7dCIhaPHMCvlFWFfjYpZKjQ39ot/Sd DDsRZ6gpzEB3Y/W1sd04TRUnj6Dwl9F3eON14TBJZzSAzF7m/U57E6/XqD94JPT+RwXByTWRF AzdmGftV3BSKuDAww5UC2Kfc/bybWbafUZx2sU/amp0R1lMaZuZA13KvjjYgyt+qBvYPCpMMw Gg5L6OEliCDZaiCJjiYESaOH60e29eGuZNeUjPigMSObr6YjIEriMG2JR6I44IBIB2sH/Iptd g7l9+c1AfBNgWfnfrbbTUMnYQBZ/UxIUpu2HZcR773uObHW9mr3GuHztPmlSp6aBzUrVYAbk6 /+iBrLhBwvgNuM+rZvNuDsExvBo9SdRYlaTthr7S/0thRl5i8y51uMIvKybUeylRX9b4feMik mykFAR5GrjWQENMkrwmAsIxs2VBGjIDbUXzPTk+6iHe3VfbbWytDxvJXvpiNEvRdikVslbn/M bvJBz3yOY7fSJyD/pyoLmS3oTbbzJ8lbDGqGC+cqcvdShAL7m30cGCMrXOyj33Y4cfa0VW/d X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:116302 Archived-At: Dmitry Gutov 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--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.