Hi Stefan,
I do know why I was getting HTTP 500, it isn't a mystery... It was part of
my effort to troubleshoot this issue. When sending a DAV request to "/"
(not my repo root), I had mod_dav pick it up but I didn't actually
configure anything for mod_dav there, so the connection thread would error
out and die. Not a problem, it was just one of my ways of probing at the
issue to understand the behavior better (for both the working clients and
the non-working one). I created a handful of "alternate" httpd.conf
configurations that worked for the functional client but failed (with
different errors) in the non-functional client, so it was a willful action
on my part to generate HTTP 500, among others (temp redirect, perm
redirect, dav not supported, internal error) - at no point was the server
producing these codes unexpectedly, I just wanted to know how the clients
reacted... the "good" one succeeded in all configurations, and the "bad"
one failed all of them (each time just reporting the error in the repo
browser window and giving up, never following up with a GET request).
But I sort of resolved this.
It became clear that that I couldn't troubleshoot further without going
through code, so I set up an environment and branched off the tag for
1.13.1... RepositoryBrowser.cpp, TrySVNParentPath(), line 5092, I commented
out:
<code>
if (m_bSparseCheckoutMode)
return false;
if (!m_bTrySVNParentPath)
return false;
</code
I'm not sure why it cares at this point if it's in "sparse checkout mode,"
since it should only ever try to read it if it got back an error from the
server on a DAV request, and the operation is in an initialization anyway.
Might be important if we're checking out immediately from the context menu,
I guess, but in my case I'm just trying to load the repo browser to browse,
no checkout involved,
No idea why it might be set to sparse checkout mode. I am not doing
anything that I'm aware to cause that, at least not anything I'm not doing
from the working client. But this workaround did the trick, and I'm not
sure exactly what scenario will fail by leaving that commented out... seems
like worst case it attempts a GET at the wrong time, but the previous
request would have to fail to reach there, so in a practical sense it may
not matter. Nonetheless, it would take someone more familiar with the code
and with svn to determine why that logic was put there in the first place.
And I basically nullified the setting for TrySVNParentPath... theoretically
no different than stock behavior (without reg key overriding it).
Unfortunately, attaching a debugger isn't really possible with my setup. I
guess I'm content with my patch, as long as you don't think it will cause
some adverse behavior down the line. I suppose I could fill it with trace
messages and chase it further that way... I'll see how much I care after
some sleep. Long night chasing down environment gremlins. :-)
Actually, completely unrelated, but there was one environment issue I just
worked around rather than solve... the msi apparently
needs crtmfc\win32\Microsoft.VC142.CRT\vcruntime140_1.dll on the win32
build, but this file doesn't exist. vcruntime140.dll did exist in that
folder, and both existed for the x64 version of the path. So I'm not sure
how the win32 for 1.13.1 ever created the msi successfully. I guess the
file might be living in someone's working copy but never added.
Thanks,
Joe
On Saturday, August 15, 2020 at 1:48:11 AM UTC-4 Stefan wrote:
> Yes, if the registry key does not exists it defaults to true.
> But you really, really should check your server logs because a 500 error
> means that the server crashed, and you really should figure out why.
> Another thing: since TSVN uses URLDownloadToFile
> <https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/ms775123(v=vs.85)>to
>
> get the web page for the SVNParentPath url, you might want to check the
> security settings on your server.
> See here for one possible problem/solution:
> https://groups.google.com/g/tortoisesvn/c/X0l-ZKgiy3U/m/YLncn-CECAAJ
>
>
--
You received this message because you are subscribed to the Google Groups
"TortoiseSVN" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/tortoisesvn/afb72ab2-5d3c-43dd-96b1-f1b4625e31den%40googlegroups.com.
