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 

Does that still cause problems under to policies described above?


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 >
Flightgear-devel mailing list

Reply via email to