bug#58525: 28.1: `vc-dir' (key sequence: C-x v d) fails when used with a CVS repository

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 16 Oct 2022 22:06:41 +0000 (UTC)
> From: Mark Harig <idirectscm@aim.com>
> Cc: "58525@debbugs.gnu.org" <58525@debbugs.gnu.org>
> 
> > 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.

We seem to be using "repository" in different meanings here.  What I
mean by that is the local checkout of the (potentially) remote
upstream repository.

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.

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

Doesn't happen to me with Emacs 28, FWIW.  But I did that without
creating a new repository from scratch; I just used an existing
checkout of some CVS repository I have here.  So maybe something in
your complex recipe trips Emacs?

> 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.

That is what happens for me: Emacs says "No VC backend is responsible
for ~/tmp1".

> 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

Doesn't happen here.

I also reproduced your setup from the original report, and I don't see
the problems you reported.  vc-dir behaves correctly for me in that
case, recognizing tmp3/project1 as being under CVS and showing the
status buffer as expected, without any errors.

So I wonder why you see these problems and I don't.  Are you sure
there are no old vc*.el files on your system that shadow the ones
provided with Emacs?

> 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.

Emacs 28.1, Bash 4.4.20, CVS 1.12.13 here.