Bug#270693: svnadmin dump | svnadmin load cycle not working due to 2GB limit
[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. Likewise, libsvn0-dev is being renamed to libsvn-dev, which makes more sense anyway. I notified the maintainers of packages that use libsvn0 about a month ago, so they'll be ready to rebuild when this happens. Peter signature.asc Description: Digital signature
Bug#270693: svnadmin dump | svnadmin load cycle not working due to 2GB limit
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 ahead of you. We're planning to call it libsvn1. Likewise, libsvn0-dev is being renamed to libsvn-dev, which makes more sense anyway. Isn't libsvn1 a new upstream version number? I don't think there are any firm plans for Subversion 2 yet, but it does get discussed occasionally. I'm not sure why upstream use libsvn0 rather than libsvn1 for the current release, are you relying on the next major upstream being libsvn2 rather than libsvn1? -- Philip Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#270693: svnadmin dump | svnadmin load cycle not working due to 2GB limit
[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 the SONAME version. Truth be told, libsvn1 is closer. signature.asc Description: Digital signature
Bug#270693: svnadmin dump | svnadmin load cycle not working due to 2GB limit
[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 Debian. I am told apache 2.2 is coming to Debian experimental Real Soon Now. How soon after that it gets to unstable, none can say. Not much we can do other than follow the apache group here. Peter signature.asc Description: Digital signature
Bug#270693: svnadmin dump | svnadmin load cycle not working due to 2GB limit
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 Real Soon Now. How soon after that it gets to unstable, none can say. Not much we can do other than follow the apache group here. 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. Can Debian continue to call it libsvn0 if it's no longer compatible with older versions of libsvn0? I suppose Debian could rebuild all the Debian packages that use libsvn0, but that doesn't solve the problem for non-Debian binaries. I suspect the libsvn0 name will have to change, much like a C++ ABI transition. -- Philip Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#270693: svnadmin dump | svnadmin load cycle not working due to 2GB limit
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: Kann nicht in Datenstrom schreiben: Datenübergabe unterbrochen (broken pipe) Die maximale Dateigröße ist überschritten Does it make sense to upgrade to libapr1? This would need a recompiled subversion too, doesn't it? Thank you
