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

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]

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.

Steps to recreate the problem, using `emacs -Q':

# 1. Create a new CVS repository from a bash shell prompt:
$ cd   # Start in home directory.
$ mkdir tmp1
$ cvs -d ~/tmp1 init  # Create a new CVS repository in ~/tmp1.
$ CVSROOT=~/tmp1; export CVSROOT

# 2. Create a new project to add to the CVS repository:
$ mkdir tmp2
$ mkdir tmp2/project1
$ cd tmp2/project1
$ touch foo.txt README.txt  # Create some empty files.
$ cd ..  # Return to tmp2 directory.

# 3. Add project as a module named "project1" to the CVS repository:
$ cvs import -m "Initial versions." . project1 start
N ./foo.txt
N ./README.txt

No conflicts created by this import

# 4. Retrieve the CVS module "project1":
$ cd ..  # Return to home directory.
$ ls tmp1 tmp2  # Check directories' contents.
tmp1:
CVSROOT/  project1/

tmp2:
project1/

# 5. Retrieve the new module from the CVS repository:
$ mkdir tmp3
$ cd tmp3
$ cvs checkout project1 project1
U project1/README.txt
U project1/foo.txt

$ ls
project1/
$ ls project1
CVS/  foo.txt  README.txt

# 6. Start emacs in directory ~/tmp3/project1:
$ cd project1
$ emacs -Q

7. In Emacs, type `C-x d' (the function `dired') to list the
   contents of the initial directory, ~/tmp3/project1.  This list
   will include the subdirectory `CVS' and the two files
   `foo.txt' and `README.txt'.

8. Type `C-x v d' (the function `vc-dir') to list the VC status
   for the files in the directory.  The following error message
   will be written to the *Messages* buffer:

   vc-responsible-backend: Wrong type argument: sequencep, t
   Mark set

9. Type `C-u C-x v d' (that is, add a prefix argument to `C-x v
   d').  The following prompt will be displayed:

   VC status for directory: ~/tmp3/project1

At the prompt, accept the command by pressing the <RET> key.  The
second prompt will then be displayed:

   Use VC backend:

At this prompt, type `CVS' and press <RET> (Note that the capital
letters C V S are required).  The command completes successfully
and a *vc-dir* buffer is displayed with the VC backend correctly
identified as CVS.

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.

(End of report.)

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

[Eli Zaretskii]

> Date: Fri, 14 Oct 2022 17:36:38 +0000 (UTC)
> From:  Mark Harig via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> 
> 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.  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?

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.

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

Thanks.

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]

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

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

[Eli Zaretskii]

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

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

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

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

[Eli Zaretskii]

> Date: Mon, 17 Oct 2022 16:00:25 +0300
> Cc: 58525@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> 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.

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]

> > From: Dmitry Gutov <dgutov@yandex.ru>
> >
> > 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.)

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

[Dmitry Gutov]

On 17.10.2022 20:43, Mark Harig via Bug reports for GNU Emacs, the Swiss 
army knife of text editors wrote:
> 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?

It tries to use the most specific one, by using the sorting logic at the 
end of vc-responsible-backend. That was added in 
https://debbugs.gnu.org/42966, which should have made it into Emacs 28.1.

I'm not sure why your CVS value in that list is t and not a string: that 
should have been fixed in Emacs 28.1 as well, in revision 
bc636515884530f0cab6f.

There was a further fix, though (regarding expanded vs abbreviated file 
names) which is only available on master (bug#57777). But I'm not sure 
if that comes into play here.

Anyway, are you really using Emacs 28.1? If not, try that, if yes: could 
you try building Emacs from master? And seeing whether it fixes your 
problem.

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]

> It tries to use the most specific one, by using the sorting logic at the
> end of vc-responsible-backend. That was added in
> https://debbugs.gnu.org/42966, which should have made it into Emacs 28.1.
>

It appears that `vc-responsible-backend' DOES include the sorting
code that you have described (and which is listed as a patch in
42966).  In fact, that sorting code is included in the excerpt
from that function that I included in my previous message.

> I'm not sure why your CVS value in that list is t and not a string: that
> should have been fixed in Emacs 28.1 as well, in revision
> bc636515884530f0cab6f.
> 
> There was a further fix, though (regarding expanded vs abbreviated file
> names) which is only available on master (bug#57777). But I'm not sure
> if that comes into play here.
> 
> Anyway, are you really using Emacs 28.1? If not, try that...

The command `emacs-version' reports that it is 28.1.  Also,
/usr/share/emacs/28.1/lisp/vc-dir.el includes the following that all
appear to indicate that the file is from at least 28.1, or later:

;; Copyright (C) 2007-2022 Free Software Foundation, Inc.

(defface vc-dir-header '((t :inherit font-lock-type-face))
  "Face for headers in VC-dir buffers."
  :group 'vc
  :version "28.1")

(defface vc-dir-header-value '((t :inherit font-lock-variable-name-face))
  "Face for header values in VC-dir buffers."
  :group 'vc
  :version "28.1")

(defface vc-dir-directory '((t :inherit font-lock-comment-delimiter-face))
  "Face for directories in VC-dir buffers."
  :group 'vc
  :version "28.1")

> if yes: could
> you try building Emacs from master? And seeing whether it fixes
> your problem.

The problem is fixed for me by removing or renaming my ~/.git/
directory.

To reproduce the problem, create a ~/.git/ directory and then
follow the recipe in the original problem report.  Those steps
take less than 10 minutes to reproduce the problem, using Emacs
28.1, bash, and cvs.  Please let me know if those steps do not
reproduce the problem with Emacs 28.1.

(End.)

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

[Dmitry Gutov]

On 18.10.2022 04:06, Mark Harig wrote:
> To reproduce the problem, create a ~/.git/ directory and then
> follow the recipe in the original problem report.  Those steps
> take less than 10 minutes to reproduce the problem, using Emacs
> 28.1, bash, and cvs.  Please let me know if those steps do not
> reproduce the problem with Emacs 28.1.

When I tried to follow your steps (not in HOME toplevel, though, but in 
a subdirectory), I got this:

Debugger entered--Lisp error: (wrong-type-argument sequencep t)
   #f(compiled-function (d1 d2) #<bytecode -0xaf17ad190f8dc52>)((Git . 
"~/examples/emacs-debbugs-58525/") (CVS . t))
   sort(((CVS . t)) #f(compiled-function (d1 d2) #<bytecode 
-0xaf17ad190f8dc52>))
 
vc-responsible-backend("/home/dgutov/examples/emacs-debbugs-58525/tmp3/pro...")
   vc-dir("/home/dgutov/examples/emacs-debbugs-58525/tmp3/pro..." nil)

Not sure how you get to the step of being prompted for the backend.

This should be fixed in Emacs 28.2 released in September. 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51800 says Emacs 29 only, 
but it's been backported.

Since you are not seeing the exact error for some reason, it's possible 
that your problem has not been fixed still. But try Emacs 28.2 at least.

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]

> When I tried to follow your steps (not in HOME toplevel, though, but in
> a subdirectory), I got this:
> 
> Debugger entered--Lisp error: (wrong-type-argument sequencep t)
>   #f(compiled-function (d1 d2) #<bytecode -0xaf17ad190f8dc52>)((Git .
> "~/examples/emacs-debbugs-58525/") (CVS . t))
>   sort(((CVS . t)) #f(compiled-function (d1 d2) #<bytecode
> -0xaf17ad190f8dc52>))
> 
> vc-responsible-backend("/home/dgutov/examples/emacs-debbugs-58525/tmp3/pro...")
>   vc-dir("/home/dgutov/examples/emacs-debbugs-58525/tmp3/pro..." nil)

Yes, that appears to be the problem described, namely, the error:

   vc-responsible-backend: Wrong type argument: sequencep, t

is reported.  Thank you for reproducing the problem reported for
Emacs 28.1.

After finding the CVS backend, the `mapcar' expression in the
function `vc-responsible-backend' continues (erroneously?)
looking for additional VC backends by "walking up the directory
tree" (indirectly, via `vc-call-backend'), where it eventually
finds a "~/.git/" directory.

> Not sure how you get to the step of being prompted for the backend.

From the original report, here is Step 9.  Adding a prefix (that
is, C-u) to `C-x v d' will get a prompt for the VC backend.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58525#5

> > 9. Type `C-u C-x v d' (that is, add a prefix argument to `C-x v
> >    d').  The following prompt will be displayed:
> > 
> >    VC status for directory: ~/tmp3/project1
> > 
> > At the prompt, accept the command by pressing the <RET> key.  The
> > second prompt will then be displayed:
> > 
> >    Use VC backend:

> This should be fixed in Emacs 28.2 released in September.
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51800 says Emacs
> 29 only, but it's been backported.
> 
> Since you are not seeing the exact error for some reason, it's
> possible that your problem has not been fixed still. But try
> Emacs 28.2 at least.

If the Emacs maintainers say that they have verified (by
following the steps needed to produce the problem in Emacs 28.1)
that the problem reported for Emacs 28.1 has been fixed in a
later release, then that should complete this process.

(End.)

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

[Dmitry Gutov]

On 18.10.2022 18:39, Mark Harig wrote:
>> Not sure how you get to the step of being prompted for the backend.
> 
>  From the original report, here is Step 9.  Adding a prefix (that
> is, C-u) to `C-x v d' will get a prompt for the VC backend.
> 
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58525#5

Sorry, missed that.

>>> 9. Type `C-u C-x v d' (that is, add a prefix argument to `C-x v
>>>     d').  The following prompt will be displayed:
>>>
>>>     VC status for directory: ~/tmp3/project1
>>>
>>> At the prompt, accept the command by pressing the <RET> key.  The
>>> second prompt will then be displayed:
>>>
>>>     Use VC backend:
> 
>> This should be fixed in Emacs 28.2 released in September.
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51800 says Emacs
>> 29 only, but it's been backported.
>>
>> Since you are not seeing the exact error for some reason, it's
>> possible that your problem has not been fixed still. But try
>> Emacs 28.2 at least.
> 
> If the Emacs maintainers say that they have verified (by
> following the steps needed to produce the problem in Emacs 28.1)
> that the problem reported for Emacs 28.1 has been fixed in a
> later release, then that should complete this process.

Yup, looks fixed in Emacs 28.2.

Closing. Thanks for the report.