[27609] in Athena Bugs
Re: Odd behaviour with CVS under ubuntu 12.04
daemon@ATHENA.MIT.EDU (Jonathan Reed)
Tue Oct 30 15:08:08 2012
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Jonathan Reed <jdreed@mit.edu>
In-Reply-To: <201210281931.q9SJV9eO006898@outgoing.mit.edu>
Date: Tue, 30 Oct 2012 15:07:44 -0400
Message-Id: <05A85F46-43CA-4E1D-BA2C-676748C04B30@mit.edu>
To: Carl Alexander <xela@mit.edu>
Content-Transfer-Encoding: 8bit
Cc: bugs@mit.edu
Errors-To: bugs-bounces@mit.edu
Hi Alex,
I don't use CVS, but with some basic testing, I'm not able to reproduce the behavior. If you don't set CVSROOT, I assume you have a ~/.cvsrc that specifies a root directory? If you weren't able to reproduce it consistently, it's going to be hard to debug, but without further information, I'd be tempted to blame some AFS or network event that prevented cvs from reading your ~/.cvsrc? I assume you would have noticed in the course of your login session, but did you confirm that you had valid AFS tokens at the time of the failure? If it happens again, please let us know, and please give us a copy of your ~/.cvsrc, the output of "env", the output of "tokens", and the output of the same CVS command with the "-t" flag added.
Thanks,
Jon
On Oct 28, 2012, at 3:31 PM, Carl Alexander wrote:
> When I logged into mkc --- which is running amd64_ubuntu1204
> Debathena --- I wanted to work on one of my dotfiles:
>
> xela@mary-kay-commandos:~/cvsroot/xela/dotfiles$ cvs diff bash_alias
> cvs diff: No CVSROOT specified! Please use the `-d' option
> cvs [diff aborted]: or set the CVSROOT environment variable.
>
> This struck me as odd, because I routinely use CVS without that
> environment variable. I later checked on linerva, and got the
> expected behaviour:
>
> xela@dr-wily:~/cvsroot/xela/dotfiles$ cvs diff bash_alias
> xela@dr-wily:~/cvsroot/xela/dotfiles$
>
> Just to be sure, I ran env | grep CVS and got the same resuot on
> both hosts, namely
> CVS_RSH=/usr/bin/ssh
>
> I should note that, while I _was_ able to get the problem to
> repeat itself on a second try a few minutes after the first
> occurrance, I was _not_ able to reproduce it 20 minutes later,
> in the same window in the same login session.
>
> ---Alex
