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 20:09:49 +0200 Message-ID: <87potxwd1u.fsf@gmx.de> References: <6ok2vyzwf9.fsf@fencepost.gnu.org> <08f70cda-44be-0657-e50a-2b2c80d2c21c@yandex.ru> <87mvphnoei.fsf@gmx.de> <874mbawp84.fsf@gmx.de> <878u0llwq6.fsf@gmx.de> <0455367c-8ece-3520-a79e-6b08110e8108@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1460311879 16802 80.91.229.3 (10 Apr 2016 18:11:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 10 Apr 2016 18:11:19 +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 20:11:18 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 1apJpM-0001XE-NW for geb-bug-gnu-emacs@m.gmane.org; Sun, 10 Apr 2016 20:11:16 +0200 Original-Received: from localhost ([::1]:36182 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apJpI-0002RN-NP for geb-bug-gnu-emacs@m.gmane.org; Sun, 10 Apr 2016 14:11:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56010) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apJpD-0002Nn-Mf for bug-gnu-emacs@gnu.org; Sun, 10 Apr 2016 14:11:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1apJp8-0001U2-KG for bug-gnu-emacs@gnu.org; Sun, 10 Apr 2016 14:11:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45149) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apJp8-0001Tx-GE for bug-gnu-emacs@gnu.org; Sun, 10 Apr 2016 14:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1apJp8-0008AN-4v; Sun, 10 Apr 2016 14:11: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 18:11: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.146031180231314 (code B ref 20637); Sun, 10 Apr 2016 18:11:02 +0000 Original-Received: (at 20637) by debbugs.gnu.org; 10 Apr 2016 18:10:02 +0000 Original-Received: from localhost ([127.0.0.1]:57485 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1apJo9-00088x-U0 for submit@debbugs.gnu.org; Sun, 10 Apr 2016 14:10:02 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:62170) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1apJo7-00088O-GE for 20637@debbugs.gnu.org; Sun, 10 Apr 2016 14:10:00 -0400 Original-Received: from detlef.gmx.de ([87.146.53.247]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M4TgW-1bjKfc0L2C-00yiNt; Sun, 10 Apr 2016 20:09:52 +0200 In-Reply-To: <0455367c-8ece-3520-a79e-6b08110e8108@yandex.ru> (Dmitry Gutov's message of "Sun, 10 Apr 2016 19:00:41 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-Provags-ID: V03:K0:fe2BvjPbDgHB+YuhsE3uVJAesV8Zh/FtoH+p/RGXWGPy6exoTze JwIA1rmK+naX4zyO/4zbvz13pcDFHsrTuiYCAPEFNqh4UPkAvwodjAe+7PCkBTdPFFnufAw nDXLfhTD/dwUiOpnx4+LAUsp4/fqaRgmktixzZvDnybuzE5oNhZXWcz6EMkIP3++RulcVxW RTY82UHkZvR7jyas+v1fg== X-UI-Out-Filterresults: notjunk:1;V01:K0:UCdmfRjomRU=:qlkkSoAUyyGW3Re0k/kJp3 KTtf1RfzV9VVsFUbTmeiDCtYkK2ExQ4YCOrRMXokMXBMLs9xKX+z4MliYSeZFcxQplgBFJEcD y0Pb/EbCrBVBnJouRicdmck94mjAIOMP4i/Si/mIkQwcyNTst2jjkBeJNNvUa3Gdn/FJEJHw3 n/AMGIBdfGxoS0UlKiNPT4AA9H5tX56XKk6Xp92rIw9fNo/rWEAHI3YZ3/YGjuzDz7ociYT4N MDZMJ0ZzvJO/p26h1MuiC1QGm9UR9Gjp/r6oomPLuRtrBKL2vU9WVLM11U6Lnqf2HJPF9sVLg XGZFOE0uRYew8C1PCEsG+N1tdnjULJpyq3m/KHU/7mAYPbjUEsjhkQ6uUFNrCPtNu3nbmWGH7 nhlj723W+IdrMAj0RqpVh/iZpPQLToc21cIEnE1CYfKXnjx2af2s7KW5pBtgohqcKU2zvtOxx ikhPSzsJGbNK6gb6ft8CW2FhMq/hKDysBUrd7V7yVNl6nk/cIk7qNNsn4xI5QXsKzud7CjZgQ lbmY+QzQfCm6ahqoVd+gSaI/NSIzQuUHtdGTvgAjQB8kSDrWl323vFXxTrolcL1jrOsdtmsHL feYVnG7+s00ViE/KegEaJsEC6ZNaXAR9g++C361awx5c1A/cYH0pOR13yIhtiuc0jU+v5LwRH Y7WEpLq1K5XrkX1hx5B5lLhi3tkhypTZuaQhhkc8nct/HvyD2jJZxPB76490g1PYExV73t3I0 fmekaRs57FSf6dVI/zwY5fDYy/uBJfDfBfNqU5oKh6Ckq+h4KaXyyRZiGkMRfDs5Ne7dA4b4 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:116338 Archived-At: Dmitry Gutov writes: > On 04/10/2016 11:00 AM, Michael Albinus wrote: > >> 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. > > Why not revert 7f9b037245ddb662ad98685e429a2498ae6b7c62? I believe > I've mentioned that suggestion before. Why that? That patch fixes problems. How would you solve them otherwise? And what problem has been introduced with that patch? This one we are speaking about, bug#20637? Maybe you have mentioned this already, and I've overseen this. > The only difficulty here, as far as I'm concerned, is to update the > corresponding tests so they don't break, but are not disabled, and > still look somewhat reasonable. That's where the merge conflict > concerns come into play. But "no disabled tests" is not a hard > requirement for release anyway. Could you show a patch which reverts 7f9b037245ddb662ad98685e429a2498ae6b7c62, and also updates the tests? Maybe it is simpler to speak about this concrete proposal. >> 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. > > Not because it's too difficult to resolve. But nobody has taken any action for more than 10 months :-( >> 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. > > I agree with the sentiment, but not with certain choices of the areas > to "stabilize" it in. You've basically been discovering aspects of the > current commands and functions that are poorly specified. But those > aspects (with some exceptions, I suppose) are not regressions from > Emacs 24. They have been there for a while. Oh, there are regressions. ESR has undertaken his rewrite of vc*.el end of 2014. Emacs 25.1 is the first release which brings them to the public. See also vc.el, and compare the functions listed in the Commentary section between Emacs 24.5 and 25.1. Read also "Changes from the pre-25.1 API" at the same place in the 25.1 version of vc.el. Unfortunately, etc/NEWS of Emacs 25.1 is very silent about those changes. >> I don't care whether we discuss it here, in bug#19548 or in the >> emacs-devel ML. > > I don't mind too much any way, but 19548 is for the manual and such. A > separate bug report (or several) or discussions on emacs-devel seem > preferable. Unless I'm mistaken about these problems being orthogonal, > of course. I might be wrong, but Glenn didn't write this bug only because of some missing docs. I believe he was unhappy about the whole process, how those changes did arrive. But I'm not Glenn, and I shouldn't interpret too much ... >> ... 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). > > In general, VC supports the lowest common denominator across the > backends. Or at least, a feature should be supported in a few > important ones. CVS is on its way out, and ClearCase is a relatively > niche tool. You have read my comment in vc-tests.el? At least CVS, RCS and SVN seem to behave this way. So it is reasonable to handle the case, that directories are registered. > Anyway, the point is VC is for people to be able to write code > depending on the public API and see it work across many VCSes. And Git > and Mercurial, at least, don't track directories. So what? We could say in the doc that registering directories is not supported for all backends. People who write a backend know what they do. I hope. >> Therefore we shall precise the docstring of >> vc-backend, that it returns the backend also for directories for VCSes >> which support rgistration of directories. > > Why? Just tell anyone who wants to know a directory's backend to use > vc-responsible-backend instead. I have no problem to recommend vc-responsible-backend. But vc-backend does already TRT: when a directory is registered, it returns the backend name. When a directory is not registered, it returns nil. This is *not* a statement why a directory is not registered, and whether registering directories is possible at all for a backend. >> 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. > > We could, but honestly, that question doesn't sound particularly > important right now. Yes, it's a wart, and if there are no users that > pass a list to it, we can remove this possibility. > > Note that vc-backend and vc-responsible-backend have different > performance characteristics (and, I imagine, different behavior in > case of nested repositories), so simply replacing all uses of the > former with the latter is not a good idea. I haven't proposed this! I simply want to understand (and document) what both functions are doing. Which of them is taken by a backend is the decision of the maintainer of the backend. I'm pretty much in favor to also document the differences in performance. >> 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. > > Interactive use would be a strong justification. vc-register can be > used interactively, and it's called from vc-next-action. I haven't spoken about vc-register. I have spoken about vc-registered. This one exist as general function, and it isn't interactive. > How will we use vc-unregister? Every backend can use it instead of its backend specific function, like vc-git-unregister. It runs common code then like removing properties, and calls the backend specific function then. >>>> 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. > > That seems very low priority. I wonder how often vc-transfer-file gets > used in practice these days. I understand that's low priority for you, and I accept this. For me, while extending vc-tests.el, it isn't low priority. I need solid ground under my feed, and therefore I'm starting with the very basic functions. Understanding, testing, maybe fixing bugs, maybe improving documentation. Function by function. >> And I'm still in favor of adding vc-unregister in vc.el. > > I don't really mind. So I will do, unless somebody stops me :-) Best regards, Michael.