Bug 219367

Summary:	svnlite update fails with "E175003: Attempt to fetch capability 'depth' resulted in 'yes'"
Product:	Base System	Reporter:	Andreas Schwarz <bugs.freebsd.asc>
Component:	arm	Assignee:	freebsd-arm (Nobody) <freebsd-arm>
Status:	Closed Overcome By Events
Severity:	Affects Some People	CC:	marklmi26-fbsd, russ.haley
Priority:	---
Version:	CURRENT
Hardware:	arm
OS:	Any

Description Andreas Schwarz 2017-05-18 00:48:22 UTC

When running a "svnlite update", it fails with : 

  "E175003: Attempt to fetch capability 'depth' resulted in 'yes'".

It's not only affecting to me, there are other reports at the freebsd-arm mailing list.

After some investigation I found out, when using a older svnlite binary from r314301, then 
all is working like expected.


root@pizelot:/usr/src # uname -a
FreeBSD pizelot.schwarzes.net 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r318315: Tue May 16 01:06:37 CEST 2017     root@pizelot.schwarzes.net:/usr/obj/usr/src/sys/RPI2-B-ASC  arm


root@pizelot:/usr/src # svnlite update                 
Updating '.':
svn: E175003: Attempt to fetch capability 'depth' resulted in 'yes'


root@pizelot:/usr/src # svnlite info
Path: .
Working Copy Root Path: /usr/src
URL: http://svn.freebsd.org/base/head
Relative URL: ^/head
Repository Root: http://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 318315
Node Kind: directory
Schedule: normal
Last Changed Author: ngie
Last Changed Rev: 318315
Last Changed Date: 2017-05-15 21:58:01 +0200 (Mon, 15 May 2017)


root@pizelot:/usr/src # /tmp/svnlite.r314301 update
Updating '.':
A    sys/dev/cxgbe/crypto
U    sys/dev/mpr/mpr_mapping.c
U    sys/dev/mpr/mpr_pci.c
[...]

Comment 1 Mark Millard 2017-05-18 01:04:43 UTC

(In reply to Andreas Schwarz from comment #0)

Just a workaround FYI (without reverting
svnlite):

My workaround has been to revert to using:

svn://svn.freebsd.org/base/head

instead of something http based, such as:

http://svn.freebsd.org/base/head

Others have also reported this workaround
on the lists.

The problem seems to be protocol specific
in some way.

Comment 2 Russell Haley 2017-07-28 20:06:23 UTC

*** Bug 221070 has been marked as a duplicate of this bug. ***