On Thu, Oct 13, 2016 at 1:22 PM, Ivan Zhakov <i...@apache.org> wrote: > On 12 October 2016 at 22:30, Johan Corveleyn <jcor...@gmail.com> wrote: >> On Wed, Oct 12, 2016 at 10:13 PM, <i...@apache.org> wrote: >>> >>> Author: ivan >>> Date: Wed Oct 12 20:13:24 2016 >>> New Revision: 1764536 >>> >>> URL: http://svn.apache.org/viewvc?rev=1764536&view=rev >>> Log: >>> * STATUS: Veto r1759116 group. >>> >>> Modified: >>> subversion/branches/1.9.x/STATUS >> ... >>> @@ -135,6 +119,24 @@ Candidate changes: >>> Veto-blocked changes: >>> ===================== >>> >>> + * r1759116, r1759117, r1759122, r1759123, r1759124 >>> + Fix FSFS format 7 packing for revisions packs with lots of changes. >>> + Justification: >>> + Problem occurred in at least two user repositories. Without the fix, >>> + format 7 repositories with an exceptionally large number of changes in >>> + a pack cannot be packed - which renders using f7 pointless for those >>> + users. >>> + Branch: >>> + ^/subversion/branches/1.9.x-fsfs-pack-fixes >>> + Notes: >>> + r1759116 adds a workaround for trunc() corrupting apr_file_t internal >>> state. >>> + r1759117-23 provide the actual fixes. >>> + r1759124 adds a regression test with the necessary internal API >>> changes. >>> + Votes: >>> + +1: stefan2 >>> + -1: ivan (apr_file_trunc() bug should be reported and fixed in APR, >>> + not by unreliable workaround with unknown consequences) >>> + >> > [...] >> So that leaves you claiming that it's an "unreliable workaround with >> unknown consequences". Why? Please clarify. We are talking about a >> bugfix which fixes an important problem reported by users. Do you have >> any suggestions for improvement? Perhaps the fix should be technically >> discussed on the mailing list? Or should we just leave this important >> problem unfixed? > > I think it's almost always better to solve the problem in its origin. > Any workaround is unreliable, so we should always try to fix the > problem at the root before trying the workarounds. Note that we are > talking about a relatively obvious bug in other Apache's project, not > about something irrecoverable. > > As far as I know, this problem has never been reported to the APR's > dev list. And this is the first action that we should have done. > >> Do you have any suggestions for improvement? > I have plans to send a patch to APR in order to solve this problem. So > we don't need to release this workaround.
Okay, I understand this should be fixed in APR. But should we block a workaround in our code for a bug that causes problems in the wild for existing svn 1.9 installations? Those users deserve a fix in a 1.9.x patch release, IMHO. If you can arrange this by fixing it in APR, creating a patch release of APR, and then creating a 1.9.x svn release with that fix (in a reasonable timeframe), then fine. But otherwise I think a svn-internal-workaround is warranted. -- Johan