From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#20637: incompatible, undocumented change to vc-working-revision Date: Sun, 10 Apr 2016 21:58:02 +0300 Message-ID: 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> <87potxwd1u.fsf@gmx.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1460314753 28027 80.91.229.3 (10 Apr 2016 18:59:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 10 Apr 2016 18:59:13 +0000 (UTC) Cc: 20637@debbugs.gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Apr 10 20:59:12 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 1apKZj-0003LG-KV for geb-bug-gnu-emacs@m.gmane.org; Sun, 10 Apr 2016 20:59:11 +0200 Original-Received: from localhost ([::1]:36312 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apKZi-0000Wn-QS for geb-bug-gnu-emacs@m.gmane.org; Sun, 10 Apr 2016 14:59:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39823) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apKZd-0000TX-Vi for bug-gnu-emacs@gnu.org; Sun, 10 Apr 2016 14:59:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1apKZa-0003VT-O3 for bug-gnu-emacs@gnu.org; Sun, 10 Apr 2016 14:59:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45184) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apKZa-0003UF-Ja for bug-gnu-emacs@gnu.org; Sun, 10 Apr 2016 14:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1apKZZ-0000ro-Sx for bug-gnu-emacs@gnu.org; Sun, 10 Apr 2016 14:59:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 Apr 2016 18:59:01 +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.14603146943268 (code B ref 20637); Sun, 10 Apr 2016 18:59:01 +0000 Original-Received: (at 20637) by debbugs.gnu.org; 10 Apr 2016 18:58:14 +0000 Original-Received: from localhost ([127.0.0.1]:57521 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1apKYo-0000qe-Gs for submit@debbugs.gnu.org; Sun, 10 Apr 2016 14:58:14 -0400 Original-Received: from mail-wm0-f46.google.com ([74.125.82.46]:37663) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1apKYm-0000qP-OA for 20637@debbugs.gnu.org; Sun, 10 Apr 2016 14:58:13 -0400 Original-Received: by mail-wm0-f46.google.com with SMTP id n3so78797494wmn.0 for <20637@debbugs.gnu.org>; Sun, 10 Apr 2016 11:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=YFOVxd1OlsJy/1Hq0XMcQ/SRPbOQE8XeGMX0oH2e2Ow=; b=PqDdZNrB5yfl8fzLeqtJTnm4aHHqjpepzTf2hJMnliEhun6FbL+kAUwUfy4RWlac7N pppVzzSLrTzDLyCu440er3zX7J7CDsfeBoqnhu0gvn/xfXedw/DwmK3Ny0z1dQ2gzvG5 Hmsd2QOk/GQr9LArZwk/DGaQdM/aXXXG0/YX6EHBX231i3QAs4yhmPE0qG5T8ebmiNnk O6bvWknBh+z3hzrer/yx5OyWQkXAw48ghjTPWUmp8Udb+npPZk5RHsfF4Sa1H0mWW0zf 2pAL4AqrtpMIKWEU5pILnRAf06AGsvqdcaFMmbSQCBm1XBFcJmt8X3f+0k9eX3LCnZYA dy5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=YFOVxd1OlsJy/1Hq0XMcQ/SRPbOQE8XeGMX0oH2e2Ow=; b=E6hSXOdZLaHWxckdZJC4MksI6giHvqajeAuZyutb6uqn/VloqRJdpZEGwp/QhjuSKg kw/YsIMFB7FosdGvF93XmJJf0ZXF5SBXBwqkcIGahtb+olz7ry1bQhZpSjyTibDyaCKJ ZQ0i6IjNOTzadWufMwgV+PVd/L0IKBouKANmKtqMMmuu5e+AVibqx1PzAOTxYyznwYpv l4rT5GBZF7UFyrj7NaUBjeYwYhNFLJDcqfO3lfg5n0Cu6lHcdrQ8Xv7Q0TLOfeH1qx1b UtJyCqKY2nu0PpQ7Zo7TBsYuvdfODrT6Urcqh1pyd3WMLtOR1Wp2qj/izpyaoN5uGzdp iCqg== X-Gm-Message-State: AD7BkJIXRtrQlRcQ3ar9dHgbHOHy5bFPjqtC+9oIeVBfChz/Nrldhl7CEM3HfLEkU3Jh3A== X-Received: by 10.28.145.196 with SMTP id t187mr13975317wmd.81.1460314686997; Sun, 10 Apr 2016 11:58:06 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id a73sm13552700wme.2.2016.04.10.11.58.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 10 Apr 2016 11:58:06 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 In-Reply-To: <87potxwd1u.fsf@gmx.de> 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:116343 Archived-At: On 04/10/2016 09:09 PM, Michael Albinus wrote: >> Why not revert 7f9b037245ddb662ad98685e429a2498ae6b7c62? I believe >> I've mentioned that suggestion before. > > Why that? That patch fixes problems. How would you solve them otherwise? It just fixed the tests you've introduced a little while before that. I'm not aware of any related bug reports. The new tests assumed new semantics, so you fixed them by changing semantics, thereby causing the "incompatible, undocumented change". > And what problem has been introduced with that patch? This one we are > speaking about, bug#20637? Yes. > Maybe you have mentioned this already, and > I've overseen this. I wrote about that in the very first message to this thread: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20637#10 > Could you show a patch which reverts > 7f9b037245ddb662ad98685e429a2498ae6b7c62, and also updates the tests? > Maybe it is simpler to speak about this concrete proposal. Unless you have a different proposal, I'll write and simply commit that patch. >>> 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 :-( I would expect that to be the responsibility of the person who caused the breakage. > 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. There are regressions, but the questions you've been asking don't seem to number among them. > Unfortunately, etc/NEWS of Emacs 25.1 is very silent about those > changes. That's bug bug#19548. Could we keep that discussion out of this one? > 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 ... This bug is about vc-working-revision. It's in the title. >> 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? Which comment are you referring to? > At least CVS, RCS and SVN seem > to behave this way. You've mentioned that in the previous message. Out of these three, only SVN is in any way recommended for production use these days. In any case, they're aging and only decreasing in popularity. > So it is reasonable to handle the case, that > directories are registered. I do not understand this argument. >> 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? "So what" doesn't seem like a meaningful response to the first sentence above. > 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. We could say a lot of things. We could even say that every backend behaves in its own special way (and enumerate all those ways), but where will that get us? Again, what's the benefit of introducing this complication? > 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. It just does the thing that's more convenient for each backend. That doesn't make it TRT. > This is *not* > a statement why a directory is not registered, and whether registering > directories is possible at all for a backend. Indeed, and that's a problem: if the caller receives nil, it cannot know whether that's because the directory is not a part of a VCS checkout, or because the backend does not support tracking directories. This is a reason not to support calling vc-backend on directories: it leads to unportable code. >> 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! Good. I've just made a guess on why you've asked the question, and 7f9b037245ddb662ad98685e429a2498ae6b7c62 hinted at that conclusion. > I simply want to understand (and document) what > both functions are doing. OK. It's not like I'm a big hoard of knowledge about them. To answer the questions, I've just looked at their definitions and usages. > Which of them is taken by a backend is the > decision of the maintainer of the backend. I don't understand this. What kind of decisions would backend maintainers make about them? > I'm pretty much in favor to also document the differences in performance. OK. > I haven't spoken about vc-register. I have spoken about > vc-registered. This one exist as general function, and it isn't interactive. I see. But vc-registered is a relatively meaty function, and it has two callers outside of tests. That looks better justified to me. >> 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. vc-git-unregister has no internal callers. Anyway, please go ahead with `vc-unregister' is you feel so strongly about it. > 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. My point was, the `unregister' command is a fringe one, not a basic one. > Understanding, testing, maybe fixing bugs, maybe improving > documentation. Function by function. Sure. But I think we should fix the current bug first.