[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#58525: 28.1: `vc-dir' (key sequence: C-x v d) fails when used with a
From: |
Eli Zaretskii |
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 09:06:54 +0300 |
> 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, Mark Harig, 2022/10/14
- bug#58525: 28.1: `vc-dir' (key sequence: C-x v d) fails when used with a CVS repository, Eli Zaretskii, 2022/10/14
- bug#58525: 28.1: `vc-dir' (key sequence: C-x v d) fails when used with a CVS repository, Mark Harig, 2022/10/16
- bug#58525: 28.1: `vc-dir' (key sequence: C-x v d) fails when used with a CVS repository,
Eli Zaretskii <=
- bug#58525: 28.1: `vc-dir' (key sequence: C-x v d) fails when used with a CVS repository, Dmitry Gutov, 2022/10/17
- bug#58525: 28.1: `vc-dir' (key sequence: C-x v d) fails when used with a CVS repository, Eli Zaretskii, 2022/10/17
- bug#58525: 28.1: `vc-dir' (key sequence: C-x v d) fails when used with a CVS repository, Mark Harig, 2022/10/17
- bug#58525: 28.1: `vc-dir' (key sequence: C-x v d) fails when used with a CVS repository, Dmitry Gutov, 2022/10/17
- bug#58525: 28.1: `vc-dir' (key sequence: C-x v d) fails when used with a CVS repository, Mark Harig, 2022/10/17
- bug#58525: 28.1: `vc-dir' (key sequence: C-x v d) fails when used with a CVS repository, Dmitry Gutov, 2022/10/18
- bug#58525: 28.1: `vc-dir' (key sequence: C-x v d) fails when used with a CVS repository, Mark Harig, 2022/10/18
- bug#58525: 28.1: `vc-dir' (key sequence: C-x v d) fails when used with a CVS repository, Dmitry Gutov, 2022/10/18