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 sales@march-hare.com.
tmh at nodomain.org (Tony Hoyle) writes: > >> Checking in xyz.txt; > >> R:/Repo/xyz.txt,v <-- xyz.txt > >> new revision: 1.8; previous revision: 1.7 > >> done > > It looks like you're using a network share in local mode, unless I'm reading > you incorrectly. Thanks for the comment, Tony, but in this case the output is misleading. We're working in pserver mode without repository prefix because that feature seemd to cause trouble long time ago when we first tested CVSNT. Maybe I should mention that there is a network share access set-up on my workstation because I run a local ViewCVS-Testserver. But this has no drive letter assigned (it's not R:...), I'm using UNC for this. And none of the developers with the problems on discussion here have this access method. I'll try to give an overview of our installation - maybe someone sees any problems with it: Server is a Windows 2000 Server System also used for terminal services. It's running CVSNT build 77a with three repositorys resting on local drive R:. (The drive letter is setten up like this because of the terminal server funktionality). The only installed protocol dll is pserver (intranet-use only). Authentication goes over the passwd file without impersonation. Because of ancient Novell 4 the user accounts arn't even known by the server. The clients are working with Windows NT4, 2000 and XP, with CVSNT build 72 and WinCVS 1.3.12.1 (beta 12, some still with beta 10). They use a CVSROOT like ":pserver:user at internal.dns.name:R:/Repo/A". The developers having problems have the editor Visual SlickEdit open all the time. I could repeat the hang one time with this tool open, but it never happened again from then on. It was my hope to find the problem there but it could be unrelated. What can you all suggest? I could try to run a batch-commit one a developers machine to repoduce the problem with -t option but I had no luck when trying this on my workstation even with hardest VSlick-usage. Or is there any possibility to generate trace output to a logfile on the server? I'm feeling really helpless with this. Any comment would give me new hope... Thanks, OK.