Your message dated Sun, 12 Jun 2011 13:00:58 +0000 (UTC)
with message-id <[email protected]>
and subject line Re: Bug#350913: cvs: working directory must be checkout to work
has caused the Debian Bug report #350913,
regarding cvs fails on <working_dir>/file under some conditions
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
350913: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350913
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: cvs
Version: 1:1.12.9-17
Severity: normal

I have a default $CVSROOT value on all my accounts, even when the
corresponding directory isn't a valid CVS repository. When I want
to do some operation on a working directory, cvs shouldn't look at
$CVSROOT since the working directory has the necessary information
about the corresponding CVS repository. However one can see that
this is not the case, and cvs may fail even when the $CVSROOT value
is useless:

For instance, I have a working directory ~/software/rox/rox, and
I can do:

dixsept:~/software/rox/rox> cvs log README
[output: log of the README file]
dixsept:~/software/rox/rox> cd ..
dixsept:~/software/rox> cvs log rox/README
cvs [log aborted]: /home/vlefevre/cvsroot/CVSROOT: No such file or directory

I shouldn't have got an error here.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14.4-20051215
Locale: LANG=POSIX, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)

Versions of packages cvs depends on:
ii  debconf [debconf-2.0]         1.4.70     Debian configuration management sy
ii  libc6                         2.3.5-12   GNU C Library: Shared libraries an
ii  libpam-runtime                0.79-3     Runtime support for the PAM librar
ii  libpam0g                      0.79-3     Pluggable Authentication Modules l
ii  zlib1g                        1:1.2.3-9  compression library - runtime

Versions of packages cvs recommends:
ii  emacs-snapshot-gtk [info-br 1:20060120-2 The GNU Emacs editor (with GTK+ 2.
ii  emacs21 [info-browser]      21.4a-3      The GNU Emacs editor
ii  info [info-browser]         4.8-4        Standalone GNU Info documentation 
ii  konqueror [info-browser]    4:3.5.1-1    KDE's advanced file manager, web b
ii  netbase                     4.24         Basic TCP/IP networking system

-- debconf information excluded


--- End Message ---
--- Begin Message ---
Vincent Lefevre dixit:

>For instance:
>
>ypig:~> cvs log web-arenaire/arenaire.css
>cvs log: No CVSROOT specified!  Please use the `-d' option
>cvs [log aborted]: or set the CVSROOT environment variable.
>zsh: exit 1     cvs log web-arenaire/arenaire.css
>
>where web-arenaire is the working copy.

Yes, that’s the expected behaviour. I think. ;-)
Not as for the “why not”, it’s not my place to say.

>Well, I no longer have a CVSROOT, but the problem remains (it was
>not due to the CVSROOT... However it seems that a spurious CVSROOT
>made the command work while it was not intended to work).

The part about a spurious CVSROOT setting making it _work_ when it
normally fails (as above) is the real problem. This is why I think
setting $CVSROOT is (almost) always wrong.

>So, if you think that there would be no benefits, you can close the
>bug.

There were about 130 open bugs when I took over CVS a month and a
bit ago, and the sheer amount takes me a lot of time to reclassify
all the bugs each time I do some triaging, so I think the benefits
of leaving the bugreport open don’t outweigh these of closing it,
from a maintainer PoV. Of course, you’re free to bring the issues
up with upstream ☺ but thank you, closing.

bye,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.           -- Andreas Bogk über boehm-gc in d.a.s.r


--- End Message ---

Reply via email to