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=60134791&iu=/4140/ostg.clktrk
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
