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

[Göktuğ Kayaalp]

On 2016-10-15 16:06 +0200, jca@wxcvbn.org (Jérémie Courrèges-Anglas) wrote:
[... snip ...]
> 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--

I see the expected output, i.e. without the leading `.//'.

> The result looks like this in vc-dir:
[... snip ...]
>                          ./
>     edited               .//testfil
>                          subdir/
>     edited               .//subdir/subfil
> -->8--

Again I have no problems.

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

See below.

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

It does contain `testfil', when you `cvs import', it registers and
commits all the files in the current tree (‘ls -R /tmp/cvsroot/test/’).
I do not experience these problems, so maybe they've to do with the
OpenBSD version of CVS (they have their own copy under
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/gnu/usr.bin/cvs/ which
doesn't seem to be up-to-date, and seems that they cherry-pick patches
as NEWS and ChangeLog are 20 years old there).  I think vc.el is
supposed to display the state of the repo, not interpret it, though the
its would know better than me.  This is (and the initial ‘./’) probably
an issue of OpenBSD's fork of GNU CVS.

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

Probably the code passes ‘./’ on all setups but they just handle it
fine.  Your OpenBSD CVS (not OpenCVS, it's their re-implementation of
CVS) is probably a bit divergent from mainstream CVS and thus these
problems.  I guess if you used mainstream CVS, it'd work OK.

Maybe these need to be reported on OpenBSD bugtracker.  I'm reluctant to
trying to guess what CVS wants to way WRT file names, but I can work on
it if that's considered a better approach.

-- 
İ. V. Göktuğ Kayaalp                           <http://www.gkayaalp.com>
                        PGP pubkey: <http://www.gkayaalp.com/pubkey.asc>