Re: LSH - how is it for you?

[Neil Jerram]

>>>>> "Jim" == Jim Blandy <address@hidden> writes:

    Jim> I've encountered some bugs in Emacs with downloading diffs in
    Jim> the past.  Could you verify the problem using CVS directly
    Jim> from the command line?

As I mentioned below...

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

However, briefly experimenting with the few scheme.texi changes that I
have uncommitted right now, `cvs diff' works every time, whereas `M-x
ediff-revision' is wrong as described below.

So right now, it does seem that `cvs diff' is less problematic than
ediff-revision.

As far as I can remember, `cvs diff' goes wrong pretty reliably when
the diffs are substantial enough.  I can't get it to go wrong at all
today though!  I just tried copying posix.texi to scheme.texi, then
`cvs diff scheme.texi', and the result was fine.

So perhaps we should focus on the Emacs problem and the general
slowness only.

Regards,
        Neil

    Jim> Neil Jerram <address@hidden> writes:

    >> 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
    >> 
    >> _______________________________________________
    >> Guile-devel-internal mailing list address@hidden
    >> http://mail.gnu.org/mailman/listinfo/guile-devel-internal