[cvsnt] Re: RC4 glitches or features...?

Oliver Giesen ogware at gmx.net
Mon Aug 15 16:43:11 BST 2005


Oliver Giesen wrote:

> > The only reason this could happen is to send crashdumps to
> > cvsnt.org.  If it's crashing it would be good to know why.
> 
> If it's crashing it's not doing it very loudly. The commands run
> through just fine for all I could tell (and even exit with code 0
> according to WinCvs). I'll do some more tests today with trace and
> client logging turned on. Stay tuned.

Hmm, maybe I was no longer awake enough when I wrote my first report...
Revised report follows:
- This only happens when using the :ssh: protocol (to SF.net in my
case).
- The command never executes correctly.
- The crash appears to happen very early on. cvsagent does not even
kick in yet and no client logs get written.
- It seems that WinCvs was suppressing the crashdump notification
popup. When running from the commandline I can see it counting down.
- Sample output:

D:\Dev\Ext\cvsgui>cvs -tttt up -P
16:51:50:   -> Tracelevel set to 4.  PID is 2196
16:51:50:   -> Session ID is 8944300ac0668e8
16:51:50:   -> Session time is Mon Aug 15 14:51:50 2005
16:51:50:   -> OpenPolicy returned c0000022
16:51:50:   -> CVS Server is acting as standalone
16:51:50:   -> CVS Directory is C:\PROGRA~1\cvsnt
16:51:50:   -> main loop with
CVSROOT=:ssh;ver=2:ogiesen at cvs.sf.net:/cvsroot/cvsgui
16:51:50:   -> Exception caught - in minidumper
16:52:12:   -> send=1
16:52:12:   -> Dumping to <.snip.>

I have now sent a full crash dump. Hope this helps.


> > Yes.. I prefer having -d the default.
> 
> Hmm, I'll put in some Entries.Static then. I only needed the stuff
> required for the installer really and being able to update with a
> single command invokation rather than one non-recursive one for each
> directory would have been rather nice.

Creating an Entries.Static in the top-level CVS folder did not give the
desired effect (as I should have expected as I realize now). So, is
using cvs -f the only way to get what I want here?


Some more strange things I found while updating back and forth between
various sticky tags and the trunk from the CVSNT repository:

- I never ever see a single [P]atched line being output. All files
appear to be [U]pdated always.

- Some files fail to update to the desired sticky tag with rather
strange results and error messages. Apparently these are files that
have previously been renamed.

Starting out with a clean trunk checkout of the cvsnt module, executing
the following commands in the windows-NT subfolder should illustrate
this:

cvs up -lrCVSNT_2_5_02_2057
type CVS\Entries
cvs up -lrCVSNT_2_5_02_2054
type CVS\Entries
dir
del /q *.*
cvs up -lrCVSNT_2_5_02_2054
type CVS\Entries
cvs up -lA
type CVS\Entries
dir

If you want I could post the full session log including my output but
so far this happens consistently enough for me that I don't think this
will be necessary.

Cheers,

-- 
Oliver
----  ------------------
JID:  ogiesen at jabber.org
ICQ:  18777742     (http://wwp.icq.com/18777742)



More information about the cvsnt mailing list