Unreliability in CVS access

[Richard Stallman]

Has anyone investigated this problem?  It is a serious problem,
which is why I put it in FOR-RELEASE.

There used to be a bad interaction between CVS and SSH.
A year ago I convinced the CVS developers to make a change
designed to solve the problem.  Is this that same problem?
I am not sure, but the fact that the problem never happens
with Emacs 21 suggests the bug is in Emacs.

JD Smith, are you using CVS thru SSH?
Does the problem go away with the latest CVS?
Does the latest CVS contain a fix for the problem
as they discussed it a year ago?


To: address@hidden
From: JD Smith <address@hidden>
Date: Mon, 17 Apr 2006 12:34:19 -0700
Lines: 18
Message-ID: <address@hidden>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Complaints-To: address@hidden
X-Gmane-NNTP-Posting-Host: turtle.as.arizona.edu
User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table)
Subject: CVS issues
X-BeenThere: address@hidden
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Emacs development discussions." <emacs-devel.gnu.org>
List-Unsubscribe: <http://lists.gnu.org/mailman/listinfo/emacs-devel>,
        <mailto:address@hidden>
List-Archive: <http://lists.gnu.org/pipermail/emacs-devel>
List-Post: <mailto:address@hidden>
List-Help: <mailto:address@hidden>
List-Subscribe: <http://lists.gnu.org/mailman/listinfo/emacs-devel>,
        <mailto:address@hidden>
Sender: address@hidden
Errors-To: address@hidden
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on monty-python
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed 
        version=3.0.4


With a recent build of CVS Emacs, I've experienced problems relating to
the "cvs" command in VC mode.  E.g. C-x v l often results in:

Process cvs killed

or sometimes "No differences" on a file which has changed.  It is
intermittent, and only about 50% of the time does the command succeed. 
Emacs 21.4 does not have this problem, succeeding every time.  These issue
also cause the log buffer window to be much smaller than it normally
would (like 3 lines high), which persists even when the command later
succeeds.

In case it matters, I have:

Concurrent Versions System (CVS) 1.11.19 (client/server)

JD