Error: svn: E175002: Processing REPORT request response failed: Premature end of file

SubGit
#1

Hi,

My subgit configure command fails on a given svn revision. It’s weird, 'cos I’m pretty sure this was ok on that repo few weeks ago (and the new revisions are way beyond this one (pb on r6492 on 17572 total !)).
Error message is the following:

Detecting peg location…
Peg location detected: r17572 Database/Trunk
Fetching SVN history…’:
r6493 fetched | 63% [|||||| ]
CONFIGURATION FAILED

error: svn: E175002: Processing REPORT request response failed: Premature end of file. (/svn/DosiViewV2/!svn/bc/6492)
error: svn: E175002: REPORT request failed on ‘/svn/DosiViewV2/!svn/bc/6492’

I tried this command to check if the revision is broken, but it finished ok:

svn checkout http://lmn-s-elara:81/svn/DosiViewV2/Database@6492

Any ideas ?

Thanks,

Antoine

#2

Hi Antoine,

the “E175002: Processing REPORT request response failed: Premature end of file” usually happens due to network problems;
In most cases increasing server-side timeout value in Apache configuration helps

http://httpd.apache.org/docs/2.4/mod/core.html#timeout

It can be set in the httpd.conf:

http://help.collab.net/topic/csvn/faq/allowcustomapacheforcsvn.html

It may worth setting the TimeOut to 600.
Another approach is to use another protocol, e.g. ssh:// or svn://.

#3

Hi Ildar, thanks for the quick reply!

I’ve tried your fix, but it didn’t help, I had the same error on the same revision.
I’m not sure it’s related to timeout, because it fails immediately, it seems that nothing is stucked.

I tried to upgrade this SVN repo, but a buggy revision prevents me to do this, and I cannot import it directly into VisualSVN, because it does not handle BdB…

Another idea I had is to call subgit configure with “–minimal-revision 6493”, but I’m not sure what I’ll get. I suppose working copy will be OK, but tags and branches older that 6493 will be lost, am I right ?

#4

Hi Antoine,

the minimal-revision option will add corresponding configuration option to the generated SubGit configuration file, so that subsequent import will start from that minimal revision. This will make the import to start since that revision, but I’m afraid this won’t help on the configuration stage (actually, this r17572 revision may also be affected during import, depending on the branches configuration as SubGit may translate configured branches history beyond the minimal revision in some cases).

You’re probably right about timeout, especially if there’s no delay prior to the fault, but still, this issue happens when the network communication is broken. It might be caused by timeouts, but it might as well be caused by other limitations, such as number of bytes transferred. Lack of permission might also be the cause, by the way, it would worth to check it as well, I assume.

Honestly, I didn’t get you mention about upgrade: did you mean you tried to upgrade SVN version on your server? What is the buggy revision that prevents the upgrade from success, is that the same r17572? And which way you tried to use to import the repository to VisualSVN, dumping and importing the repository or some other way?

So, as I mentioned, on way to resolve the problem is to resolve the very problem that causes the network interruption, yet it’s not clear to the very end what it actually is. Also, the issue might be worked around – one way is to use another protocol but http, for example, svn or ssh, those are not apt to issues like this one. Also, it’s possible to use file:// protocol if it’s allowed to run SubGit on the same machine where SVN resides – in fact, this would be the best way as the network is fully excluded and protocol overhead is minimal. Another possible way is to not to use layout auto option during the configuration creating the standard configuration instead – in this case SubGit won’t scan the repository history and thus won’t hit the issue. To not to hit the issue during the import, SubGit may be set to use http spooling:

[svn]
    …
    httpSpooling = true

but I must say this way does not 100% guarantee the resolution as, for example, if that is permissions issue, then it’ll still be there.

#5

Hi Ildar,
Thanks for all your clues ! I finally managed to import my SVN repo using “-layout std” (as you suggested) but, since my layout was non-standard, I manually updated this in the config file before the import. And it went ok !
Thanks again,
Antoine

#6

Hi Antoine,

thank you for letting me know, glad to hear it worked well!