On Mon, Dec 27, 2021 at 4:52 PM Daniel Sahlberg <daniel.l.sahlb...@gmail.com> wrote: > I've been looking through JIRA to find a fun holiday project and instead > found some issues that I suggest to close. I'm putting each one under a > separate heading, with a few lines of summary as well as a suggestion for > further action (i'm not sure if every
Thanks for doing this! Responding inline below... > SVN-4848: ARM BUILD ERROR > It seems that the user had problems building Subversion on an ARM based SBC > running Debian Sarge. The user has not replied since 2020-04-01. I don't > think we have resources to support such an old version and also it seems it > was not discussed in the mailing list. > * Close as won't fix. +1. This was indeed an antique distro and compiler being used. The issue was not in SVN but in liblz4, and actually not there either but in the compiler being used not supporting certain intrinsics. I provided a workaround that should have gotten the OP past the issue and we never heard back. SVN and its dependencies are known to build on ARM with reasonably updated tools. There's nothing more we can/should do here. > SVN-3007: perl bindings segfault very often > Reported in 2007. James McCoy added a note in 2020 that it was likely fixed > in 1.9.5. > * Close as fixed. +1. We don't even support building with neon anymore, and haven't in ages. > SVN-3609: Assertion in svn_path_is_canonical, svn_path_join with 'file:' URL > This was reported in 2010 against 1.6.x. There is a comment by Julian Foad > (in 2011) that it was fixed by r1068476. The reproduction script no longer > assert. > * Close as fixed. +1. Confirmed it doesn't assert for me as well, with 1.13.x. > SVN-4578: svnadmin pack cannot delete files during packing > Reported in 2015. No comments and also not discussed in the mailing list. I > would start by looking at permissions / open/locked files before assuming a > bug. > * Close as cannot reproduce +1 on the grounds that it wasn't discussed on the list, or afterwards. I couldn't find any relevant information. > SVN-4447: Error Conflict 409 > Reported in 2013 against Subversion 1.4.x (!). If the version is correct than > it was very old even at that time. No reproduction recipe, although something > might be possible to come up with if digging deep enough. > * Close as cannot reproduce Mismatched dependencies used in the builds of SVN and HTTPD being used on the server? I vaguely remembered discussions from the distant past about that and a few quick searches did turn up some examples where that was found to be the cause. I don't know for sure if that's the cause in this specific case, but without more information it is difficult to tell. Let's assume the 1.4.x number is correct here and close it. (After all, they couldn't have mistyped 1.14.x because that hadn't been on the horizon yet.) We can always reopen it if this is found to still apply. > SVN-4639: svn.exe causes ACCESS_VIOLATION > Reported in 2016, no comments, not discussed in the mailing list. Relatively > sparse on data, I've tested using a trunk build under Windows 11 and "works > for me". > * Close as cannot reproduce I haven't looked at this one in detail yet; gotta run... I'll try to come back to it. Thanks again for looking into these! Cheers, Nathan
