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: Sun, 16 Oct 2022 22:06:41 +0000 (UTC) Message-ID: <1786309111.1655909.1665958001583@mail.yahoo.com> References: <2011444375.1250404.1665768998367.ref@mail.yahoo.com> <2011444375.1250404.1665768998367@mail.yahoo.com> <83wn926yqv.fsf@gnu.org> Reply-To: Mark Harig Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24492"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "58525@debbugs.gnu.org" <58525@debbugs.gnu.org> To: "eliz@gnu.org" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Oct 17 00:07:18 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 1okBmw-00069X-Eh for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 17 Oct 2022 00:07:18 +0200 Original-Received: from localhost ([::1]:48272 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1okBmv-00017l-Aw for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 16 Oct 2022 18:07:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39714) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1okBmh-000169-7o for bug-gnu-emacs@gnu.org; Sun, 16 Oct 2022 18:07:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47310) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1okBmg-0007HB-VF for bug-gnu-emacs@gnu.org; Sun, 16 Oct 2022 18:07:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1okBmg-00082o-JF for bug-gnu-emacs@gnu.org; Sun, 16 Oct 2022 18:07: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: Sun, 16 Oct 2022 22:07: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.166595801430907 (code B ref 58525); Sun, 16 Oct 2022 22:07:02 +0000 Original-Received: (at 58525) by debbugs.gnu.org; 16 Oct 2022 22:06:54 +0000 Original-Received: from localhost ([127.0.0.1]:46388 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1okBmX-00082Q-JT for submit@debbugs.gnu.org; Sun, 16 Oct 2022 18:06:54 -0400 Original-Received: from sonic301-3.consmr.mail.bf2.yahoo.com ([74.6.129.42]:44946) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1okBmU-000829-L5 for 58525@debbugs.gnu.org; Sun, 16 Oct 2022 18:06:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aim.com; s=a2048; t=1665958003; bh=Vak2cvs78VNPrH10MVHgUtO/cRKgmWWc4Tu9QDp2Eb4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=YOOtMmXIncCxAXbA7TaIqdm/Rm58PgA6QQ8IwbEj0+s4CQ2E2JIt9r9XXcRsEEzmtC4GiE+z5XZLcVhPrimzaGz1QXaTiDl9NhDCrQ4jKsM/oVx4imBSDhesDBeyRipFcGTcNV+8wcEP2q15HKo+ucXcNZU0tor26sXTV7xEjK8OEFYrOmnX9f16oggTPLs+eCle9A+SSkBlpqA/RiJ2ke9uI5MKek1yJ/SOA/yDI689LVTTGN/1MP5rnZAB8EKp5r/bGWPQuPOc7kW+fZZsoDtoHLTYSIG96Fbc8575EGGXrq3AnZnmhhipQwHdijiiSWe4komw8cQAv6XGMP6fOw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1665958003; bh=hcfCMPiDCrSTKxCyRKVWpNn51P7cepFLPde6QFGgw/E=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=meKxFbbDhLzYllQTUvIF2ZlcOxoUfUMvO+2PfbVwuOAnl6wUJriBYUqf8I0RHk1m2+X/H4ovQxGuBIbdrbEVOmEFWE15MewsF0aSg1JxzJwgqtWQEeW1ds4sMPoquQ7l9zoVrF1eLiKQozLfYuMID0wsFPKEcl5dTQxnp91+IyRrA0XWjYC6yEmyBYMi5q59WoxAFs5vPL4gvhMOpSAc4F/cx7PUDK0GStyekKOnnWGk6e8fEhp4kV+3RXFzJcfLKdpwZDExN5c/6/tT9GL4ymVvFQVXmBjARAxv9cea8PJlA6YL2kO3xjpDQuTOIDA8WMK8hEgNK+UrARUTkAsvAQ== X-YMail-OSG: Hkv.r24VM1mSkOhUnU1Z2E9ncfv_DFH9XoD20L4Q5fOzct4.QNH2GJnvepvLKWo n4G1obkVw4Zqsxs1XrVIXYyAdU23Rv3UjHMTgQj.gSmERX_tJNfyUXg0oF2VAllGo6GRVLJYCKYW YH8pDz6YQN4cOLQYPz317Bd6z_CgXxoa1SZLCQXkmDnFpiSbsPe1Jda8uqSP2g2HoIIecT8gDRyV D0JblzWunBrfUH03JS3b8XqPHjHUaujG13iJRUEWVzE4fj8TvgPkHZxjaCUT.paTzya4GQcLQHMv 4KfnMBtu8pJVezRncdqBrAVOUxnI_ZhPQqiCOxR7Onl7ZsiQjQKttwahjPTlw0HrXVi9mF22vldj 9289KigUwaqQRlaU86ZeVtvpiOm0nGy1kBdHaMbKTFAjghxl2Oa6vdmymF4XfriBZqWNkcGt1Usi Rk9KYnrj9.CrLD3vm2NckXYwP1Ffzun0Gw8IOuTl7BMIo2Gez0.Ih06_AoPwQBy__nHBx82hpFsk GQ6aCgbxOX7W6U5zdwsnHyXpRdmce96km0mhn1BKW9CxF2sa2TGNWKqnzqF.IiZkBLwf5QOIaiKO mKh1AzLBsqoMADXlIukxKfDocxqYd0JJaxAHvlLG9eO.UcYdEFsijlehilboe501IqUQ7.2dGuM0 E7X9ShP4BdsHOx9mZEoyCoD1qKh0lF7dAgTaKroL0AX0IgCzrh8bd1DBxxzEXXvdVGqMvgWlDm.B euRDQWSZbbPPSs_Zwcel_r8JvT7DR9nCaV93MEYVpiL2x.4zdWZNIUHkKRVTjCrjLWsHlpvirOjF 1dzjeeY2vYdmPEGX.HZRVE3YkpnHcrv_Dh.imnXmQ8 X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Sun, 16 Oct 2022 22:06:43 +0000 In-Reply-To: <83wn926yqv.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:245676 Archived-At: Thank you for your reply. > > When attempting to retrieve a VC status for a directory > > or file when the VC backend is CVS, the `vc-dir' command > > fails with an error message. > I'm not sure I understand the reason for this elaborate > setup. The reason for it is to provide a means to reproduce the problem, starting with a newly-created CVS repository (in ~/tmp1), a small number of (empty) files in the new repository, a separate work directory (~/tmp3) into which the files are "checked-out" from the new repository, and an Emacs session with no local customization. Doing this eliminates possible complications that could be a source of the problem reported. > It sounds like CVSROOT is in ~/tmp1, but you expect Emacs > to understand that ~/tmp3/project1, which is outside of > the ~/tmp1 tree, is part of the CVS repository in ~/tmp1?=C2=A0 > Why is the correct expectation? It is correct that the *repository* is in ~/tmp1. But the repository could be remote and accessed, for example, using ssh. It is not necessary to be in the directory that contains the CVS repository. Users of the (central) repository do not need direct access to the CVSROOT directory and do not even need to know that it exists. All access (reading/writing/differences/status/logging) to the CVS repository are done via the cvs commands. Note that, as the Emacs user manual points out, CVS is not a distributed, decentralized system, but, rather, is a centralized system that has a single repository, not a copy of the repository (as is the case with git and other VC backends). Copies of files are retrieved from that (either local or remote) repository, along with text files (that are created by `cvs') that provide information about the central repository, among other information. When the `cvs checkout' command is issued in Step 5, the sub-directory "project1" is created by `cvs'. In the "project1" sub-directory, `cvs' creates another sub-directory called "CVS". In the CVS sub-directory, a (plain) text file named "Root" is created. The "Root" text file contains the location of the (possibly remote) repository. > FWIW, "C-x v d" in a CVS repository (i.e. a directory > which has a 'CVS' subdirectory) does not signal an error, > and displays the correct VC status of the files. What you have described is what is supposed to happen (using Emacs 28.1), but it does not. Instead, `emacs -Q' issues the error message listed in the original error report. (I have confirmed this multiple times following the instructions in the original report.) > > So, the code for `vc-dir' (or, key sequence C-x v d) contains an > > error in which it cannot correctly identify the VC backend if it > > is not provided, when the VC backend is CVS. > Please tell how Emacs was supposed to realize that > ~/tmp3/project1 directory is a CVS repository. ~/tmp3/project1/ directory is NOT a CVS repository. The recognition should be that "project1" is a directory that is available in the (central) CVS repository by verifying the presence of the ~/tmp3/project1/CVS/ sub-directory and the ~/tmp3/project1/CVS/Root file, which specifies the location of the central repository. When the `cvs checkout' command in Step 5 is completed, the ~/tmp3/project1/ sub-directory will have been created along with ~/tmp3/project1/CVS/ sub-directory and ~/tmp3/project1/CVS/Root text file (among other text files). Note that if `C-x v d' is issued for ~/tmp1 (which contains the CVSROOT and project1 sub-directories), then `vc-dir' makes two errors: 1. There is no CVS sub-directory in ~/tmp1 and no Root text file, so `vc-dir' should issue an error indicating that there it cannot recognize any VC backend or that there is no means for it to get the status of the files in the sub-directory. 2. In addition to failing to recognize the absence of a VC backend, `vc-dir=E2=80=99 makes the mistake of displaying a *vc-dir* buffer with an invalid status. In the *vc-dir* buffer, the first line listed is: VC backend : Git This erroneous status is produced for any directory that does not contain VC backend files, rather than an informational message stating that there is no VC status to report. Again, note that if a prefix argument is provided to `C-x v d', and "CVS" is provided when prompted for (Use VC backend:), then `vc-dir' gives the correct results, provided that the directory it is working on contains a sub-directory named CVS and that sub-directory contains a text file named Root. So, the error in `vc-dir' is that it does not correctly (initially) recognize the VC backend for CVS. But if `vc-dir' is provided the name of the VC backend, then it is able to interact correctly with the CVS repository that ~/tmp3/project1/CVS/Root specifies. > Thanks. Thank you for your attention on this. Please let me know if there is more information that you need. It should be possible to reproduce the problem using the steps in the original report. For completeness, here are the versions of the tools used to create the problem: bash-5.2.2, cvs-1.11.23, emacs-28.1. (End.)