LSH - how is it for you?

[Neil Jerram]

So we've been using the new CVS repository at subversions.gnu.org for
a couple of months now, with LSH instead of SSH.  My experience is
that the new setup

- is much slower than the old one at Red Hat, for all operations

- almost always shows incorrect diffs to me.

The first point is self-explanatory.

For the second point, here's exactly what I mean...  I like to check
my diffs before committing by using `M-x ediff-revision' in Emacs.
Most of my recent work has been on guile-doc/ref/scheme.texi, which is
a _big_ file.  9 times out of 10 when I do an `M-x ediff-revision' on
scheme.texi, what I see is

- the real diffs

- one or more big spurious diffs which can be interpreted as missing
  chunks of text in the last committed version that was just
  downloaded as part of `M-x ediff-revision'.

As far as I've worked out, ediff-revision downloads the last committed
version using a command of the form `cvs update -rX.XX' - so it's
pretty worrying if that can result in a file with missing chunks!

Sometimes I get effectively the same problem with `cvs diff' on the
command line.  More commonly, though, I get a different problem with
`cvs diff': the output is simply truncated in the middle of a line,
without even a line feed character before the next shell prompt.

If I do `cvs update -rX.XX' on the command line, it (so far) works
correctly every time.  That at least is reassuring.

So, does anyone else experience these problems, and what can we do
about them?  I'm happy to help with the debugging effort, but I'm not
really sure where to start.

(That said, a hypothesis has emerged from the writing of this email:
the common link could be the behaviour of `cvs update' when its output
is something other than just a plain file.)

In case it's relevant, I'm connecting from the UK using a PPP dialup
connection with a 28.8 modem.

Regards,
        Neil