Re: git-cvsserver wart?

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: May 25, 2006, 21:19 UTC
Message-ID: <46a038f90605251419kd45fbj419565eabdd63182@mail.gmail.com>
In-Reply-To: <dcedf5e20605250942g6a7417dfh5f2f26df29842def@mail.gmail.com>

On 5/26/06, Cameron McBride <cameron.mcbride@gmail.com> wrote:

Show 6 quoted lines

> For reasons I won't go into, the ability to use cvs clients is darn
> near crucial.  Although most development is local (where I install /
> use git), pulling down the latest updates and pushing up minor changes
> via CVS is helpful at remote locations where I don't want to maintain
> clients.  Git with git-cvsserver makes this very nice.   Thanks to
> all!

NP!

There's been some recent changes to cvsserver -- so version info is crucial. What git version are you using? Can you try with the lastest #master head from Junio? That's the latest and greatest...

If that doesn't fix it, can you post the logs? I think you have to declare CVS_LOG=/tmp/cvslog or somesuch.

> code/ntropy> cvs -v
> Concurrent Versions System (CVS) 1.11.1p1 (client/server)

We've developed it testing against 1.12.9 from debian and 1.11.20 from MacOSX/fink.

> so, it's an old client, a newer client doesn't have this problem.  a
> bare 'cvs up' works fine on:
> Concurrent Versions System (CVS) 1.11.17 (client/server)

Ah! Then capturing the logs of the working and non-working clients, and comparing them can probably help. Can you capture and post the relevant parts of the log...?

> p.s.  I'm assuming the following statement is harmless (it's always present):
> closing dbh with active statement handles

Yup. Harmless indeed. They way we are using prepared statements, I don't know how to avoid it :-/ -- suggestions welcome.

cheers,

martin