subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <...@daniel.shahaf.name>
Subject Re: svnsync: E175002: REPORT request on '/<ROOT>/!svn/rev/<N>' failed
Date Mon, 17 Dec 2018 09:55:52 GMT
Nick Burkitt wrote on Fri, 14 Dec 2018 12:36 -0800:
> The operation proceeds without problems until it gets to revision 71, at
> which point it fails with the error "svnsync: E175002: REPORT request on
> '/<ROOT>/!svn/rev/71' failed". I've looked at all the related answers I
> could find, but none of them address this specific problem.
> 

The error code is SVN_ERR_RA_DAV_REQUEST_FAILED, which doesn't add
information.

> I'd be okay with losing the first 70 revisions, but I have no idea how to
> get past this point.

I wouldn't resort to that yet.  Do you have previous backups of these
revisions?  Does «svn checkout %SOURCE_REPO%@71» succeed?  If either of
these works, you should be able to work around the error in r71.
Furthermore, —

> The master is on a CollabNet CloudForge account, so I have no visibility
> into the server side - not even SVN version. I can view revs 69 through 72
> using the repo browser without detecting any problems.
> 

The standard next step is to look in the server's log for errors.  If
you don't have access to it yourself, then you should contact your
hosting provider.  If you do this, you hopefully wouldn't have to
discard the first 70 revisions (not to mention that based on the
information available, we can't rule out the possibility that _later_
revisions will have the same error).

> The client is TortoiseSVN (command line utilities):
> PS E:\svn> svnsync --version
> svnsync, version 1.11.0 (r1845130)
> compiled Oct 30 2018, 21:50:05 on x86-microsoft-windows
> 
> How do I go about analyzing this problem? Are there diagnostic tools? Log
> files? Guys who just know the answer?

As I said, my first recommendation is to talk to your hosting provider.
If you do this, you might skip the middleman and ask them to run
'svnadmin dump --deltas foo' and send you the resulting file.  If you
they don't figure it out, _then_ would be the time to start doing
fancier things (wireshark, workarounds using previous backups and/or
'svn checkout', etc).

Cheers,

Daniel

Mime
View raw message