Cvs Commit: cvsnt

CVSROOT:	/usr/local/cvs
Module name:	cvsnt
Changes by:	[email protected]		Sat Oct 27 21:35:04 2007
On host:	mail.march-hare.com

Directory: cvsnt

M build.h		1.60 -> 1.61	Bug Id: 

Directory: cvsnt/cvsapi

M ServerIO.cpp		1.12 -> 1.13	Bug Id: 
M ServerIO.h		1.8 -> 1.9	Bug Id: 

Directory: cvsnt/cvsio/cvsiotest

M cvsiotest.cpp		1.10 -> 1.11	Bug Id: 

Directory: cvsnt/cvsservice

M Service.cpp		1.50 -> 1.51	Bug Id: 

Directory: cvsnt/cvstools/win32

M GlobalSettings.cpp		1.14 -> 1.15	Bug Id: 

Directory: cvsnt/evsfs/evsfstest

M evsfstest.cpp		1.9 -> 1.10	Bug Id: 

Directory: cvsnt/extnt

M extnt.cpp		1.6 -> 1.7	Bug Id: 

Directory: cvsnt/src

M buffer.cpp		1.20 -> 1.21	Bug Id: 
M client.cpp		1.177 -> 1.178	Bug Id: 
M import.cpp		1.99 -> 1.100	Bug Id: 
M main.cpp		1.152 -> 1.153	Bug Id: 
M main.h		1.5 -> 1.6	Bug Id: 
M server.cpp		1.213 -> 1.214	Bug Id: 
M server.h		1.39 -> 1.40	Bug Id: 
M subr.cpp		1.92 -> 1.93	Bug Id: 

Directory: cvsnt/windows-NT

M win32.cpp		1.124 -> 1.125	Bug Id: 

Log message:
If ServerTaceFile was set in the registry in the server then there 
were crashes.

If -ttt was specified on the client there were crashes, the server
trace came back without "S" prefixes and could also break the
protocol.

Basically this fix re-enables tracing (both server side and client
side) that appears to have been broken up until now.

I still do not understand why there is a separate _servertrace 
function that displays messages in a different format to the
rest of the system (there seems no good reason not to use cvs_trace)
except that cvs_trace was completely broken, so _servertrace was
perhaps just a workaround.

Fixing this seems to have affected many other parts of the system,
which could be that the trace messages were sending junk into
the protocol, or it could be a sign of more serious undiagnosed
problems (eg: evs rls used to fail with a user permissions failure
but suddenly started working with these changes).