From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Mark Harig via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#58525: 28.1: `vc-dir' (key sequence: C-x v d) fails when used with a CVS repository Date: Mon, 17 Oct 2022 17:43:07 +0000 (UTC) Message-ID: <259751090.1922936.1666028587272@mail.yahoo.com> References: <2011444375.1250404.1665768998367.ref@mail.yahoo.com> <2011444375.1250404.1665768998367@mail.yahoo.com> <83wn926yqv.fsf@gnu.org> <1786309111.1655909.1665958001583@mail.yahoo.com> <837d0z3rwh.fsf@gnu.org> <9490cc5d-5d0f-4ef6-d00b-0629853aaa22@yandex.ru> <83pmeq1k9e.fsf@gnu.org> Reply-To: Mark Harig Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7057"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "58525@debbugs.gnu.org" <58525@debbugs.gnu.org> To: "eliz@gnu.org" , "dgutov@yandex.ru" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Oct 17 19:44:52 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1okUAV-0001ft-UY for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 17 Oct 2022 19:44:52 +0200 Original-Received: from localhost ([::1]:42974 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1okUAU-0004Br-Of for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 17 Oct 2022 13:44:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40954) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1okU9l-0004An-HP for bug-gnu-emacs@gnu.org; Mon, 17 Oct 2022 13:44:11 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50832) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1okU9i-0004Rn-H3 for bug-gnu-emacs@gnu.org; Mon, 17 Oct 2022 13:44:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1okU9i-0001Ej-3u for bug-gnu-emacs@gnu.org; Mon, 17 Oct 2022 13:44:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Mark Harig Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 17 Oct 2022 17:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58525 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 58525-submit@debbugs.gnu.org id=B58525.16660285984687 (code B ref 58525); Mon, 17 Oct 2022 17:44:02 +0000 Original-Received: (at 58525) by debbugs.gnu.org; 17 Oct 2022 17:43:18 +0000 Original-Received: from localhost ([127.0.0.1]:49910 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1okU90-0001DX-2A for submit@debbugs.gnu.org; Mon, 17 Oct 2022 13:43:18 -0400 Original-Received: from sonic302-3.consmr.mail.bf2.yahoo.com ([74.6.135.42]:45484) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1okU8w-0001DI-EM for 58525@debbugs.gnu.org; Mon, 17 Oct 2022 13:43:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aim.com; s=a2048; t=1666028588; bh=oyY43djlMXVxRFP2OGobdmEWe/p2zPbUGpHXJXVoH1Q=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=e+bjIjmH+EbdFPLiR1/RTvaOf8mGFOc8H3nceafwaxefI6gI2CxZWBFaf3RqRoI/JE3z/wmBjAfhH45fPUqxi11YjPASGStiZbs/m4iAM2m6PsArMh2t/tcktXn0rPhJIY/rRweAzw5wZWR7KpG/OTvFXgXDsWMyMr/PoKAwb5SAiaWbMvU1jKjkx1ammzFHp3hAyUYG0trhhiOMj3cqBwtZVRC/dMDSDno81T0zZUQGzfi8ELboGetQMFcgiPpFruoUlMvAdKSYje2ffNdHGKZaIFMdcJ3t8fB1j8df8gnnmSbhT7xryI6D2JG/aWX44Vh6olYluhvIMuoeRwMSTw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1666028588; bh=AqZlfLAgfbEBXjXRD3RRwlgqezIlyl44BGhaYopHwtn=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=kCY+OtyJi8LFf9j2JVx2QT4hi61VcLfwK+pgUfJ2N4XL8x0/SVQgW6+87dd7qK24Agev6S43+9yVZC8/W2Umscj4RsRUKxaIcjL43tQqREffOxriiujvO0gc7ugI4zCHwrJ0O5N3K1jTZRRmkVcsHINV6+R2gWD1llPLNHia3Bjfodawv3GdAY2TfncxmsJ5+4uSXJgdX26pG8WPsapWD0hqOm8JYieVDByOjryBOLh1mD5YyxQTf8tS9SQrKOVF9MMrWFQcPECLqU4F18WSPfPXUdZ5jb6bYv78VrO5rE9KGfQsU4F9ONHBCx1Wcz1e34yEem7Ldikh1huzA7XZ4Q== X-YMail-OSG: uABaKLMVM1nyubdj9TcLaofwxK039ZvHboLrORGRTQDydyrvKv3H5aO0vNFkoqF JfbdSLMdnq7uYwRFTM8N.cLvKbNvI_nrA6DqPuRdt9SSwfy4SH9E8ik6O5UIkFS3cjQrQCXhNk7w pUMTL433YJEVzoMlaSIUWNh8.zoGMR.G_sB2sqXy75cWAmvzVCbgG8Ue37Lcw1CX66Af118jstJx vYU32oAiM9a_3ux0XoAZqso05nP801se0b5_8SA6DCv30XeYKhSTjqN2EZlpXbnRDFro.sKnCwGO KOt7zu1hoKAQN_HiS8ctdREY53lNHp2A7HHy9GlLYujVUVeuVKyV62gt4dyxn3DQOfFXfIFuenF2 oM8BTU3Ht1QsIe5NT7_EWMb1ZUHlIClBXwZuLPI23X3ThUtXQZZ.1B1kvVktiNsDdBgndv.SNirs 5.nOcfNZrPFOWLZGWpFxYq0ykDp2WaiIVuJJqzoH_Yc57lmSjfQbMCCUiMFx06KNLvpVs7GJAHEZ 18QV1dfPcaIHWfv_M2nn9HM0jKBZ05pAT5h78wntPTcaYV9iq7S9WbFbd2MY6WsFFMKTi5SejUrc eis8HIQLkuScJfysfhv40W9jUxeMRTNfgtOGRH8z2EkCmkDCeWYP1qrIT2ehBXlKS9YjfTiijodR 6XgYZjs23S.mt1zVydfWoB8ImQmM04WFMxLweYPyIuk2LWYFxmSF7Fk7lOrK83wtEB9GTManL4nE Vitrq9xbUL0KcznVoQMKvaWzyaIUlmRjZaVMBweq3c0_5nWGuYu9I1uY8V4vyMIZyMfHYG.PGTDQ 22wAOoFMq2Zc1CEJgg16011EqUpnFjxXoyXhntKMY7 X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Mon, 17 Oct 2022 17:43:08 +0000 In-Reply-To: <83pmeq1k9e.fsf@gnu.org> X-Mailer: WebService/1.1.20740 aolwebmail X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" X-ACL-Warn: , Mark Harig Xref: news.gmane.io gmane.emacs.bugs:245747 Archived-At: > > From: Dmitry Gutov > > > > On 17.10.2022 09:06, Eli Zaretskii wrote: > > > AFAIK, the VC's support for CVS is based on detecting the CVS > > > subdirectory of a directory where you invoke vc-dir. If that > > > subdirectory is not found, VC will assume the backend is not > > > CVS. In which case your assumptions seem to be mistaken. > > > > > > But I will let VC expert to chime in here, because I may be > > > wrong or confused. > > > > Here's the basic logic: > > > > (defun vc-cvs-registered (f) > > "Return non-nil if file F is registered with CVS." > > (when (file-readable-p (expand-file-name > > "CVS/Entries" (file-name-directory f))) > > > ... > > Thanks. So after performing the steps in the original report, I do > have ~/tmp3/project1/CVS/Entries here. The `vc-cvs-registered' function is not called before the error is triggered. `vc-dir' calls `vc-responsible-backend'. `vc-responsible-backend' contains the following expression: > (let ((dirs (delq nil > (mapcar > (lambda (backend) > (when-let ((dir (vc-call-backend > backend 'responsible-p file))) > (cons backend dir))) > vc-handled-backends)))) > ;; Just a single response (or none); use it. > (if (< (length dirs) 2) > (caar dirs) > ;; Several roots; we seem to have one vc inside another's > ;; directory. Choose the most specific. > (caar (sort dirs (lambda (d1 d2) > (< (length (cdr d2)) (length (cdr d1)))))))) The value of `dirs' is set by the following expression: > (dirs (delq nil > (mapcar > (lambda (backend) > (when-let ((dir (vc-call-backend > backend 'responsible-p file))) > (cons backend dir))) > vc-handled-backends))) On my system, the `mapcar' expression is returning the following value: > (nil (CVS . t) nil nil nil nil (Git . "~/") nil) which is surprising and incorrect. The `delq' expression then reduces this to: > ((CVS . t) (Git . "~/")) So, for some reason, the VC elisp code thinks that in ~/tmp3/project1, there is both a CVS and a Git VC backend controlling the files that were checked out of the CVS repository. Because the Git cons contains "~/", I checked my home directory for files named ".git" and found a directory created two years ago. I renamed that directory and re-ran `C-x v d'. The original error reported disappeared and `vc-dir' listed the CVS status and files as expected. I restored the directory in ~/ to its original name (~/.git) and the error returned. The problem appears to be a result of the function `vc-find-root' finding the "~/.git" directory. As its doc string says: > "Find the root of a checked out project. > The function walks up the directory tree from FILE looking for > WITNESS. If WITNESS if not found, return nil, otherwise return > the root." So, after finding the CVS backend, the `mapcar' expression, above, continues and checks for a Git backend, which it finds in the directory that contains tmp3/project1, namely, ~, the home directory. Because it found ~/.git/, it sets the variable `dirs' to an erroneous value and later logic fails because of this. What is the solution to this problem? What should the VC functions (not just `vc-dir') do when they find more than one VC backend indicator in the directory tree? Should it issue an error indicating more than one VC backend detected, (since files cannot be under the control of multiple VC backends)? Or, should it stop after the "most local" VC backend is found and attempt to use that? The current behavior (issuing an obscure error message that gives the user no clue as the what is causing the problem) should be corrected. (End.)