RE: svnsync: E175002: REPORT request on '/<ROOT>/!svn/rev/<N>' failed

Hi Daniel.

I contacted CollabNet, and while they didn't find a solution to the svnsync problem per se, they did provide instructions for creating a local backup using "snvrdump dump" and "svnadmin load."
Thanks again for your help!

-Nick

-----Original Message-----
From: Daniel Shahaf [mailto:d.s_at_daniel.shahaf.name]
Sent: Monday, 17 December, 2018 01:56
To: Nick Burkitt <nick.burkitt_at_optimalranging.com>; users_at_subversion.apache.org
Subject: Re: svnsync: E175002: REPORT request on '/<ROOT>/!svn/rev/<N>' failed

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%_at_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
Received on 2018-12-28 19:19:37 CET