As of now, with these versions:
ii libapr0 2.0.55-4the Apache Portable Runtime
ii subversion 1.3.0-1 advanced version control
system (aka. svn)
svnadmin is unable to process revisions > 2GB.
Sorry for the german text:
svnadmin
[Ph. Marek]
> Does it make sense to upgrade to libapr1? This would need a
> recompiled subversion too, doesn't it?
Yes, but more importantly, if we upgrade to libapr1 we break
mod_dav_svn. It needs to use the same apr that apache is using. Thus
we will upgrade to libapr1 when apache 2.2 hits De
Peter Samuelson <[EMAIL PROTECTED]> writes:
> Yes, but more importantly, if we upgrade to libapr1 we break
> mod_dav_svn. It needs to use the same apr that apache is using. Thus
> we will upgrade to libapr1 when apache 2.2 hits Debian. I am told
> apache 2.2 is coming to Debian "experimental" R
[Philip Martin]
> Is there a Subversion packaging problem ahead? If libsvn0 starts to
> use libapr1 this will change the ABI of libsvn0 and any package built
> against the existing libsvn0 ABI may not work correctly with the new
> libsvn0.
Way ahead of you. We're planning to call it libsvn1. L
Peter Samuelson <[EMAIL PROTECTED]> writes:
> [Philip Martin]
>> Is there a Subversion packaging problem ahead? If libsvn0 starts to
>> use libapr1 this will change the ABI of libsvn0 and any package built
>> against the existing libsvn0 ABI may not work correctly with the new
>> libsvn0.
>
> Way
[Philip Martin]
> Isn't libsvn1 a new upstream version number?
Why don't you check the SONAMEs for yourself? You can do this with
objdump -p. I won't spoil the surprise, but I will say that I think
you'll discover the remarkable fact that neither "libsvn0" nor
"libsvn1" is an exact match for th
6 matches
Mail list logo
