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 19:00:41 +0300 Message-ID: <0455367c-8ece-3520-a79e-6b08110e8108@yandex.ru> 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> 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 1460304072 29260 80.91.229.3 (10 Apr 2016 16:01:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 10 Apr 2016 16:01:12 +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 18:01: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 1apHnT-0002jb-Nc for geb-bug-gnu-emacs@m.gmane.org; Sun, 10 Apr 2016 18:01:11 +0200 Original-Received: from localhost ([::1]:35470 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apHnT-00012W-0q for geb-bug-gnu-emacs@m.gmane.org; Sun, 10 Apr 2016 12:01:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58975) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apHnO-0000wv-I6 for bug-gnu-emacs@gnu.org; Sun, 10 Apr 2016 12:01:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1apHnK-0000TL-FE for bug-gnu-emacs@gnu.org; Sun, 10 Apr 2016 12:01:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45050) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apHnK-0000TH-BZ for bug-gnu-emacs@gnu.org; Sun, 10 Apr 2016 12:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1apHnK-000513-38 for bug-gnu-emacs@gnu.org; Sun, 10 Apr 2016 12:01:02 -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 16: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.146030405119257 (code B ref 20637); Sun, 10 Apr 2016 16:01:02 +0000 Original-Received: (at 20637) by debbugs.gnu.org; 10 Apr 2016 16:00:51 +0000 Original-Received: from localhost ([127.0.0.1]:57387 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1apHn9-00050X-2z for submit@debbugs.gnu.org; Sun, 10 Apr 2016 12:00:51 -0400 Original-Received: from mail-wm0-f50.google.com ([74.125.82.50]:32779) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1apHn7-00050K-Gx for 20637@debbugs.gnu.org; Sun, 10 Apr 2016 12:00:49 -0400 Original-Received: by mail-wm0-f50.google.com with SMTP id f198so116854686wme.0 for <20637@debbugs.gnu.org>; Sun, 10 Apr 2016 09:00:49 -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=LBFymFhCEuYLfvUmbE58gDshotQWf8fkOhTcNM9i52k=; b=hkjCAHsHzBG0lHW32IShGLp9DgT42oUEaSKwSHZqfpc68hSL386fwb8hnFbgccI+y4 saQ9uvvQF0DPeD7oL9JLapMhgj78KMP6IBa27yGgY2TczLVssMjWo0vtmAi/O9bvcATu t/B++R+B2PzjpzzxyWbmhCRxRvGlkS7KmRQNmQzoZWHE4j0Zl0rLMVqSWmXJnwiuZ8MU fu/v6xBHpDGP7EsepJNWgvMQ3ljQ3UdwyARWhDhcULnAlWwHp+4bjOUG6vjDVgurs1BA 6cjpYD0YKZwKGYw8j9ndkvCW2KUDMSfBpJ8s2JaOejByJdt2XIv93Qt0eWo6JOcy96Zu t4lQ== 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=LBFymFhCEuYLfvUmbE58gDshotQWf8fkOhTcNM9i52k=; b=THv93o05WqnoFhqsFyz/zHAX2e97GskM3ABsHSDlGpqcGVGhkbw79IVLHbhCfh17rH /PHFeliDiYq/zI4s0pN7DXIA/WPnMxeog8xi4Vwm8/0mC+g28ePx8T12PSFADSKKzVKB 90HA3htROETCdNU8ASirnlmy7c4k+zxFWN7cOw3pz/tZGZ3rgEfQm1wieN/z0H5RUGCJ SACz3qQsveMOZzhh+juV6obEVC9/R+T0knXohjUUGyZbg43cEuXrbb3RC+/rKBYAHpGk E0N06fj44z2KRSMykMSM9MmsLehzvd/jQ7ecy4f0SAHBM5bSxIOFy4NYGEqX/shm5D2P L1yg== X-Gm-Message-State: AD7BkJIUb3a/j/qcTeHR+9MV7UmftuHlgz9+aEQcTwHSTQptTr99X704/4bx8yuNCk/wgg== X-Received: by 10.194.172.99 with SMTP id bb3mr19842499wjc.46.1460304043786; Sun, 10 Apr 2016 09:00:43 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id a184sm12995752wma.3.2016.04.10.09.00.42 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 10 Apr 2016 09:00:42 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 In-Reply-To: <878u0llwq6.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:116322 Archived-At: 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. 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. > 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. > 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. > 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. > The docstring says nothing about directories, so the call I've applied > is legal. Best wishes to whoever wrote that docstring. > ... 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. 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. > 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 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. > 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. How will we use vc-unregister? >>> 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. > And I'm still in favor of adding vc-unregister in vc.el. I don't really mind.