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 Thanks, Garyl Erickson