Date: Fri, 4 Sep 2015 20:40:17 -0700 From: Tim Kientzle <tim@kientzle.com> To: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: very odd behaviour from svnlite on RPi2 Message-ID: <644A3890-CEF7-4ED4-BB85-616C09EE1E6F@kientzle.com> In-Reply-To: <20150904223214.GA80713@potato.growveg.org> References: <20150904173804.GA82922@potato.growveg.org> <46ddeb2caa6.2d9e5c4c@mail.schwarzes.net> <20150904223214.GA80713@potato.growveg.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Sep 4, 2015, at 3:32 PM, John <freebsd-lists@potato.growveg.org> = wrote: >=20 > On Fri, Sep 04, 2015 at 11:33:54PM +0200, Andreas Schwarz wrote: >=20 >> I got this svn errors from time to time, independently from the rpi. = For=20 >> getting and updating the ports tree, you can also use the "portsnap" = tool >> (it's part of the base system). >=20 > 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=20 > portsnap because I thought it lagged behind svn, but I might use it in = future,=20 > 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=20 > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?644A3890-CEF7-4ED4-BB85-616C09EE1E6F>