subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nick Burkitt" <nick.burk...@optimalranging.com>
Subject RE: svnsync: E175002: REPORT request on '/<ROOT>/!svn/rev/<N>' failed
Date Fri, 28 Dec 2018 18:19:16 GMT
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@daniel.shahaf.name] 
Sent: Monday, 17 December, 2018 01:56
To: Nick Burkitt <nick.burkitt@optimalranging.com>; users@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%@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