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.
> So, it sounds like the output is as it should be when "cvs info" is
invoked
Right. Apart from the missing sspi protocol as Tony has noted. Even though
that should usually be no reason for a crash. Unless it is not actually
missing but corrupted (or one of its dependencies as Tony appears to
suspect).
> In most cases, on the WinCVS side you see a table of various CVSROOT
related, which, for lack of a better,
> more definitive term, I will define as "environment variables" which are
(apparently) returned from cvs.exe to
> WinCvs.exe, including "hostname", etc., which were defined before cvs.exe
was invoked, but are no longer defined
> "by" or "within" WinCvs.exe after the cvs.exe "crash/application
abortion":
I guess WinCvs just aborts the operation altogether once it notices that
cvs.exe has crashed and thus doesn't process the output anymore. After all,
it's rather unlikely that a crashed application returns valid output despite
the crash. It surely isn't entirely trustworthy so IMO WinCvs is correct in
aborting the parsing. It might have to make it a little more clear what
happened, though...
BTW: Those "keywords" (which to my knowledge is the more accurate term for
what you labeled "environment variables") are entirely originated within the
cvs.exe . WinCvs has no idea beforehands what cvs.exe will return in reply
to the protocol query. It simply displays (and offers for modification) what
it gets. As I outlined before, the first step is to get the list of
available protocols ("cvs info"), the next is to get the available keywords
for the selected protocol ("cvs info [protocolname]"). You could just try
those commands on the commandline yourself (once the crash issue is resolved
that is).
Cheers,
--
Oliver
---- ------------------
JID: ogiesen at jabber.org
ICQ: 18777742 (http://wwp.icq.com/18777742)