bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cvs history sends incorrect data


From: Thomas Singer
Subject: Re: cvs history sends incorrect data
Date: Tue, 10 Aug 2004 11:05:38 +0200
User-agent: Thunderbird 0.7.2 (Windows/20040707)

Mark,

I was able to reproduce the weird behaviour on my _local_ Knoppix 3.3 machine.

But much more weird it is, that this problem only seems to occur, when I use SSH to communicate with the server. With local access this problem does not happen. But it could not be a problem with the SSH client or server, because everything else works fine and the 'ok' reponse also is sent correctly.

Today evening (or tomorrow) I will try to test it with CVS 1.12.9, but if nobody here knows of such a bug, I doubt, that it is fixed.

I guess, there must be some problem flushing the history's output buffer, when in 'cvs server' mode.

One more investigation result: when this problem happens, it happens reproducible on the same position (which supports the idea of unflushed buffer). A day later (or when more files got committed), it happens on a different position.

--
Best regards,
Thomas Singer
_____________
smartcvs.com


Mark D. Baushke wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas Singer <address@hidden> writes:


Hi Mark,

The CVS server is version 1.12.5. Running 'cat /proc/version' shows

 Linux version 2.4.24-xfs (address@hidden) (gcc version 2.95.4 20011002
(Debian prerelease)) #1 SMP Mi Feb 4 01:03:50 CET 2004


So, I'd guess that might be a knoppix 3.3 release
(http://www.knoppix.net/)... one thing to do if you have time is to look
and see if knoppix 3.3 had any bugs that might impacting cvs in this
case... (although, as you say it does sound like everything else is
working).


We authenticate using ssh with OpenSSH public/private-key-authentication.


Are you able to reproduce with cvs 1.12.7


Actually, the above is a typo. I intended to write cvs 1.12.9...

In any case, it might be possible to copy the CVSROOT/history file to a
different server machine in order to try to reproduce the problem (ie,
use the CVSROOT/history file as data put into an empty repository just
to see if you can get the problem to manifest itself under more
controlled conditions).


I don't know, because I cannot update our server that easily (it is
located somewhere else).


You might be able use the CVS_SERVER environment variable to specify a
pathname to a different executable on the remote system. So, all you
would really need to do to try a new server would be to get it built on
your CVS server machine (this of course depends on if you are being
forced into a restricted shell of some kind on your server or not).


That's why I asked in my first post, whether this is a known (and
maybe already fixed) bug.


Well, I have not seen this particular kind of problem reported
previously and I have not observed it myself. If it is fixed, it might
be due to other changes to the history or buffer code, but I somehow
doubt it. This is why a good test case is probably needed to help
reproduce the problem and ensure that a change to CVS really fixes the
problem.


BTW, since I cannot get CVSNT to authentication with our server (maybe
it does not support the public/private-keys?), I only can try with
SmartCVS as the CVS client.


Hmmm... your client is a Windows box of some kind?

It should be possible to use a CVSNT 2.0.51b client :extssh: mode to
talk with a CVS 1.12.7 server with SSH authentication. It should also be
possible to use Putty along with Pagent to do the connection if you don't
have any other method.

There is also a pre-built cvs.exe client for windows available here:
  https://ccvs.cvshome.org/files/documents/19/324/cvs-1-12-9.zip
which might work for you.

If your system is not a Windows environment, there may still be other
clients available, let folks know your client side if you want further
suggestions in that regard.

        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFBFkQz3x41pRYZE/gRAuDAAKCDhQCxkdg4eA+YtO6UhFJ3V2n/qACfXnPV
ri89DN2aD8jjqKt+RdodfB8=
=5xvJ
-----END PGP SIGNATURE-----






reply via email to

[Prev in Thread] Current Thread [Next in Thread]