unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Mark Harig via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: "eliz@gnu.org" <eliz@gnu.org>
Cc: "58525@debbugs.gnu.org" <58525@debbugs.gnu.org>
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)	[thread overview]
Message-ID: <1786309111.1655909.1665958001583@mail.yahoo.com> (raw)
In-Reply-To: <83wn926yqv.fsf@gnu.org>

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? 
> 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’ 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.)





  reply	other threads:[~2022-10-16 22:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2011444375.1250404.1665768998367.ref@mail.yahoo.com>
2022-10-14 17:36 ` bug#58525: 28.1: `vc-dir' (key sequence: C-x v d) fails when used with a CVS repository Mark Harig via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-14 18:34   ` Eli Zaretskii
2022-10-16 22:06     ` Mark Harig via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2022-10-17  6:06       ` Eli Zaretskii
2022-10-17 13:00         ` Dmitry Gutov
2022-10-17 16:34           ` Eli Zaretskii
2022-10-17 17:43             ` Mark Harig via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-17 23:10               ` Dmitry Gutov
2022-10-18  1:06                 ` Mark Harig via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-18 12:04                   ` Dmitry Gutov
2022-10-18 15:39                     ` Mark Harig via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-18 15:58                       ` Dmitry Gutov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1786309111.1655909.1665958001583@mail.yahoo.com \
    --to=bug-gnu-emacs@gnu.org \
    --cc=58525@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=idirectscm@aim.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).