Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to email@example.com.
Hi Jason This question relates to CVSNT or WinCVS more than CVS, so I'll redirect the it to the CVSNT forum. Which version of CVSNT are you running? Have you tried tracing it (cvs -t update/commit/...) If you upgrade to WinCVS 1.3b10 you'll notice that WinCVS now spawns a separate cvs process which might be healthier, also b10 uses the latest cvs.exe from CVSNT. Regards, anders > -----Original Message----- > From: Jason.Gibbons at intuwave.com [mailto:Jason.Gibbons at intuwave.com] > Sent: 13. november 2002 19:56 > To: info-cvs at gnu.org > Subject: Problems with WinCVS > > Just on the off chance that anyone else has had similar problems: > > We are running a cvs repository on an NT server, and are using WinCVS on > various client machines to access the repository (using NTServer > protocol). > For most people, there are no problems whatsoever. A couple of machines, > however, are throwing spanners in the works. If either one of these > machines tries to access the repository through WinCVS (version 1.2 by the > way) it will succeed once. However, in running one cvs command (be it > update, checkout, commit, log, graph or whatever) it seems to flood the > cvs > service. Any subsequent attempt by any machine (including the dodgy > machine itself) to access the cvs repository through WinCVS fails with > errors like: > couldn't connect to server: all pipe instances busy > or > couldn't connect to server named pipe error 6 > (depending on the machine). > > The remedy for the problem is to restart to cvs service on the server, but > of course the problem occurs again as soon as one of the dodgy machines > tries to do anything in cvs via WinCVS. Interestingly, however, cvs can > be > accessed via the command line on all machines at all times (i.e. even when > WinCVS is reporting the pipe errors) and if we stick to using the command > line on the dodgy machines, the problem never occurs. Clearly, then, the > issue is genuinely a WinCVS one. > > Anybody seen anything like this before? > > > > > > _______________________________________________ > Info-cvs mailing list > Info-cvs at gnu.org > http://mail.gnu.org/mailman/listinfo/info-cvs