very odd behaviour from svnlite on RPi2

Tim Kientzle tim at kientzle.com
Sat Sep 5 04:09:32 UTC 2015


> On Sep 4, 2015, at 3:32 PM, John <freebsd-lists at potato.growveg.org> wrote:
> 
> On Fri, Sep 04, 2015 at 11:33:54PM +0200, Andreas Schwarz wrote:
> 
>> I got this svn errors from time to time, independently from the rpi. For 
>> getting and updating the ports tree, you can also use the "portsnap" tool
>> (it's part of the base system).
> 
> Yeah I thought about doing this instead of svnlite (after I'd started svnlite).
> After 10 restarts I got so annoyed I made a while loop. I've never used 
> portsnap because I thought it lagged behind svn, but I might use it in future, 
> maybe it's suited more to low-power systems.

Svn should work just fine on "low power systems," but has had problems on FreeBSD-based RPi and BeagleBone for a long time.

I suspect the root cause is a bug in SVN when dealing with extremely slow disk:  I think the TCP connection times out while the svn client is doing a long series of disk operations.

It certainly should not be happening.

> I've not seen these errors on the other freebsd boxes in the logs (same 
> connection) which is why I thought it might be a bottleneck with the pi.

In some cases, I've repeated the 'svn cleanup' + 'svn up' cycle for 2-3 days before it finally completed only to see missing files that svn doesn't seem to be aware of at all.  I've found that partial tree checkouts are more likely to succeed; you can sometimes work around this by asking SVN to checkout/update individual subdirectories.

For FreeBSD source checkouts, I recommend using git which doesn't seem to suffer from this problem.  Similarly, portsnap is more resilient than svn for ports checkouts.

Tim



More information about the freebsd-arm mailing list