[cvsnt] SSPI stopped working -- how to troubleshoot

Garyl Erickson garyl at veicon.com
Wed Nov 21 18:04:28 GMT 2007

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.

Bo Berglund wrote:
> For the sspi format you have used you can do the following on a command
> prompt on the client:
> set CVSROOT=:sspi:garyl at cvs-server:/CVS-Repository
> cva logout
> cvs login
> (Now enter the password)
> This will update the cached password if successful and sspi will work
> afterwards.
Thanks so much. That worked (after I again undid the account lockout -- 
not sure why this keeps happening, but hopefully it won't any longer, 
now that the password issue is resolved).

> The only reasons to use your version of the connect string (with the
> user explicitly entered) are:
> 1) If you are logged on to the client computer as another user than the
> one you want to use for communicating with the CVS server
> 2) If the client PC is not part of the domain the cvs server is
> connected to
> 3) If the cvs server is not part of the domain the client PC is
> connected to
> 4) If you are connected via VPN or similar with difficulty getting AD
> authentication running
Makes sense; I'll drop the username in the future.

> Concerning the -d option to CVS
> This is not something you should ever do inside an existing sandbox!
I certainly agree that's not the intended usage, but sometimes things 
happen due to misunderstandings or less than optimal procedures or 
accidents. Like, while the sandbox has files that have been edited, the 
access method changes or the server location changes due to a hardware 
problem, or who knows what.
> I am surprised that it even overrides the CVS/Root files that exist in
> the sandbox, it shouldn't!
Because of cases like I mentioned, I would argue cvs should act like we 
have come to expect well-designed programs to work, such that a command 
line switch should always override an environment variable, which should 
always override a configuration file or registry setting (as in 
"CVS\Root"), which should always override a hard-coded value. Otherwise 
the command line switch and environment variable are essentially 
disabled and useless. So I would argue the -d switch should have two 
purposes, to provide a value when one doesn't exist, and to override it 
if one does exist.

> You use this typically on the command line if you are executing CVS
> commands in a folder that is not a sandbox, for example in order to
> create a sandbox by checking out a module from the server.
> Apart from that I see no valid use of that syntax. Either you are
> working inside the sandbox and then the Root files show where the files
> came from and where any operation should be directed,
... agreed, unless something out of the ordinary happened and it's no 
longer valid ...
> or you are outside a sandbox, when the -d option or CVSROOt env
> variable can be used.
> If the server has changed name then you need to modify all Root files
> accordingly, in WinCvs there is a macro to handle this for you.
Changing the environment variable or using the command line switch would 
be so much simpler, especially if there was an option to update the 
CVS\Root file.
> Best regards,
> Bo Berglund

Garyl Erickson

More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook