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

[Jérémie Courrèges-Anglas]

Göktuğ Kayaalp <self@gkayaalp.com> writes:

> On 2016-10-15 15:36 +0300, Dmitry Gutov <dgutov@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@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@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@localhost:/tmp/cvsroot/
ritchie /tmp/test$ cat subdir/CVS/Root
jca@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@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