C. Michael Pilato wrote:
>>Since I am still looking for a workaround to the blocker bug:
>I still don't know what's causing this problem, and I can't seem to
>reproduce it myself (at least, not with enscript disabled).
I re-enabled the local access viewcvs mode. Will see in a few days if we
locked up again. Remember that I'm still open to any suggestions to
investigate that. I wanted to get a python backtrace from the stalled
cgi processes, but it looks like no one even knows how to do that.
>>I decided to give it a shot, updated everything, and replaced my
>>svn_roots = radiant.svn: /mnt/d/svn/radiant.svn
>>svn_roots = radiant.svn: https://zerowing.idsoftware.com:666/radiant
>>And you can now see the error viewsvn is reporting at:
>The svn_ra ViewCVS module implements no prompting auth callbacks. If
>creds aren't cached, ViewCVS has no way to get at them. So if your
>repository has authstuffs on it, and those authstuffs aren't cached in
>the .subversion area, you won't be able to do the right thing. I
>dunno for sure, but this could be the problem, especially since
>connection to your repository requires answer an SSL cert question.
>I added 'https://zerowing.idsoftware.com:666/radiant' as one of the
>svn_roots on my own ViewCVS instance, and got the same PROPFIND
>error. I think ran 'svn ls https://zerowing.idsoftware.com:666/radiant' as
>the user whom my ViewCVS runs as, and answered "(p)ermanent" to the
>cert prompt. Now I can browse your repos.
>Of course, if you run ViewCVS as a user who has no .subversion area, I
>guess you're out of luck (unless maybe you can hack your
>svn_ra/__init__.py to point the client cfg object to a different
>config area... just thinking aloud here...)
Good catch. apache runs as 'svn/svn', is a system user with no shell and
no home. If local access still wedges, I'll see what I can do with that
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat May 8 01:44:43 2004