Re: [Flightgear-devel] Built-in Svn client code crashing
James, On 10/04/2013 08:43 PM, James Turner wrote: I haven't taken a copy of the libsubversion and forked/edited/trimmed it - it's completely unrelated code. Aha, I wasn't aware of that. Sounds like a different story, then. Does that still cause problems under to policies described above? I don't think so. Thanks for clarification. Regards Markus Wanner signature.asc Description: OpenPGP digital signature -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Built-in Svn client code crashing
On 4 Oct 2013, at 19:29, Markus Wanner mar...@bluegap.ch wrote: That smells like trouble from a packaging standpoint. It's usually not acceptable, because most of the time, the integrated library isn't getting the amount of support the original does. For Debian, I'll certainly have to consider reverting that change. Well, that might be quick tricky - the replacement code is a tiny subset of what the libsubversion code does, and behaves differently - which enables various features and different APIs which I'm planning to use going forwards. Just to be clear, I've replaced libsubversion, which is a full, read+write svn client library with support for history, logging, setting SVN properties and so on, with what is essentially a download engine which happens to speak the SVN protocol. (Which is the part of SVN we actually use). I haven't taken a copy of the libsubversion and forked/edited/trimmed it - it's completely unrelated code. Does that still cause problems under to policies described above? Regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Built-in Svn client code crashing
On 3 Oct 2013, at 12:38, Saikrishna Arcot saiarcot...@gmail.com wrote: Just to check, is the built-in SVN code effectively replacing the external SVN code (from libsvn-dev), or does it add something? Replaces it - one of the big motivations is that the libsvn dependency is becoming increasingly complex to support. (Since libsvn depends on APR, amongst other things) In Git now, all references to libsvn are gone - we always use the built-in code, and based on some limited feedback the crashes are gone. More testing is of course welcome. Regards, James -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Built-in Svn client code crashing
Hello, A few people have reported crashes when using the built-in SVN client code, especially on Linux (and potentially Windows too, which would be a problem, as we shall see). Thomas identified something strange relating to whether we were using built-in or the system Expat XML parser, and I finally realised the dumb thing I'd done, and have cleaned up the problem. Hence the refactoring that occurred in SimGear last night, so that we cannot (anymore) end up in a situation where we get the Expat headers and symbols from mismatching locations. The guess/hope is that this was previously causing subtle memory corruption due to internal differences in Expat. However, it can only have been an issue on Linux, not Windows - since Windows will never have a system-supplied version. So, as I've previously asked before, I really need people running from 'next' to try with -DSG_SVN_CLIENT=1 when configuring SimGear, move their existing TerraSync dir out the way, and test, test, test. I'm sure the new code isn't 100% trouble free (in particular I think there is still the occasional time when it gets stuck not doing any more downloads until FG is restarted), but I really don't want to move forwards with the code until I have a bit more assurance it's not going to make everyone's setup crash 80% of the time, which is what some people have reported. Note this applies even if you 'don't use' terrasync since the SVN sync engine is going to be used for other pieces of data as soon as it's stable. (I will be adding a new preference to globally control whether FG works in online/offline mode, of course) Kind regards, James -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
