GNU bug report logs - #24082
25.1; vc-dir for CVS repositories list all files as if from toplevel directory

Previous Next

Package: emacs;

Reported by: Göktuğ Kayaalp <self <at> gkayaalp.com>

Date: Tue, 26 Jul 2016 21:08:01 UTC

Severity: normal

Tags: confirmed

Found in version 25.1

Done: Dmitry Gutov <dgutov <at> yandex.ru>

Bug is archived. No further changes may be made.

Full log


Message #90 received at 24082 <at> debbugs.gnu.org (full text, mbox):

From: jca <at> wxcvbn.org (Jérémie Courrèges-Anglas)
To: Göktuğ Kayaalp <self <at> gkayaalp.com>
Cc: 24082 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#24082: 25.1;
 vc-dir for CVS repositories list all files as if from toplevel
 directory
Date: Sat, 15 Oct 2016 16:06:21 +0200
Göktuğ Kayaalp <self <at> gkayaalp.com> writes:

> On 2016-10-15 15:36 +0300, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>> On 14.10.2016 23:33, Jérémie Courrèges-Anglas wrote:
>>> In the meantime, maybe a conservative approach would be better?
>>
>> Considering it introduces a feature regression (no unregistered and 
>> ignored files in the listing) at least with some clients, I'm not sure 
>> it's best.
>>
>> And since it your case the problem is only of visual nature (diffs and 
>> navigation work all right, IIUC), the proposed more complex patch seems 
>> desirable.
>
> As I noted before I couldn't reproduce his issues and can't spot
> anything that might cause it in the patch (the code does not change the
> strings in any way, maybe apart from the call to ‘file-relative-name’ in
> the second hunk).  Hope Jérémie will be able to debug the issue.

So...,

You asked for the output of `cvs -fnq update', but in my tests the
actual command that is run seems to be `cvs -fnq update ./'.  Re-using
your instructions in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24082#33

--8<--
ritchie /tmp/test$ cvs -fnq update ./
M .//testfil
M .//subdir/subfil
-->8--

The result looks like this in vc-dir:

--8<--
VC backend : CVS
Working dir: /tmp/test/
Repository : /tmp/cvsroot/
Module     : test


                         ./
    edited               .//testfil
                         subdir/
    edited               .//subdir/subfil
-->8--

This happens for all the *local repos* I have on this machine (including
my mirrors of the OpenBSD source tree).

Adding a few file-relative-name calls around `(match-string 1)' in
vc-cvs-after-dir-status helps getting a nicer formatting.


However, there could be a nastier problem with remote repos.

--8<--
ritchie /tmp/test$ cvs -d jca <at> localhost:/tmp/cvsroot/ -fnq up
M testfil
M subdir/subfil
-->8--

All is well... note how the file names are not prefixed with `./'.

--8<--
ritchie /tmp/test$ cvs -d jca <at> localhost:/tmp/cvsroot/ -fnq up ./
cvs server: conflict: testfil is modified but no longer in the repository
C testfil
M subdir/subfil
-->8--

Oops... cvs thinks what we want to run update from the cvs root
directory (which doesn't contain `testfil').

Here I modified the Root entries to point to localhost:
--8<--
ritchie /tmp/test$ cat CVS/Root
jca <at> localhost:/tmp/cvsroot/
ritchie /tmp/test$ cat subdir/CVS/Root
jca <at> localhost:/tmp/cvsroot/
ritchie /tmp/test$ cvs -fnq up
M testfil
M subdir/subfil
ritchie /tmp/test$ cvs -fnq up ./
cvs server: conflict: testfil is modified but no longer in the repository
C testfil
M subdir/subfil
-->8--

vc-dir shows:
--8<--
VC backend : CVS
Working dir: /tmp/test/
Repository : jca <at> localhost:/tmp/cvsroot/
Module     : test


                         ./
    conflict             testfil
                         subdir/
    edited               subdir/subfil
-->8--

So with `./', files in the current directory seem to be considered as if
we were at the root of the cvs repo root directory.  Subdirectories seem
to be fine, vc-diff works fine on them.

I can't see how the code would manage to pass `./' to cvs on my setup
and not on others.  I don't know if more recent cvs(1) versions handle
`./' and remote repos in a nicer way.

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE




This bug report was last modified 8 years and 293 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.