Bug 219367 - svnlite update fails with "E175003: Attempt to fetch capability 'depth' resulted in 'yes'"
Summary: svnlite update fails with "E175003: Attempt to fetch capability 'depth' resul...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: arm (show other bugs)
Version: CURRENT
Hardware: arm Any
: --- Affects Some People
Assignee: freebsd-arm (Nobody)
URL:
Keywords:
: 221070 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-05-18 00:48 UTC by Andreas Schwarz
Modified: 2017-08-23 05:18 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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. ***