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?
On 4 Oct 2013, at 19:29, Markus Wanner 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 revertin
On 10/03/2013 01:45 PM, James Turner wrote:
> 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
On 3 Oct 2013, at 12:38, Saikrishna Arcot 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 supp
Just to check, is the built-in SVN code effectively replacing the
external SVN code (from libsvn-dev), or does it add something?
Saikrishna Arcot
On Fri 20 Sep 2013 12:53:02 PM EDT, James Turner wrote:
> Hello,
>
> A few people have reported crashes when using the built-in SVN client code,
> es
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 f
6 matches
Mail list logo