Late to the party, but: thanks for doing this. Some more below. On Tue, Dec 28, 2021 at 12:20 PM Daniel Sahlberg <daniel.l.sahlb...@gmail.com> wrote: > > Thanks Nathan for the quick review! > > I'm going to continue to add to this mail to have "one mail to rule them all" > and add more issues to the end as I go along. Please feel free to clean up > the mail when replying. > > Den tis 28 dec. 2021 kl 01:50 skrev Nathan Hartman <hartman.nat...@gmail.com>: >> >> > SVN-4848: ARM BUILD ERROR >> > SVN-3007: perl bindings segfault very often >> > SVN-3609: Assertion in svn_path_is_canonical, svn_path_join with 'file:' >> > URL >> > SVN-4578: svnadmin pack cannot delete files during packing >> > SVN-4447: Error Conflict 409 > > > I've closed the ones above.
+1 >> >> > 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. I agree you can close this as "cannot reproduce". > > SVN-667 handle file name case sensitivity edge cases > I know almost nothing about OSX file systems but I think the more modern ones > are case sensitive. This leaves win32, where (I believe) all file systems are > case insensitive but most are case preserving. According to my tests it > behaves much better than originally described. If someone on OSX could test > we should probably close this and add a new issue describing the current > state. > * Close as ... Later? Yeah, I'd say that issue is 99% solved since 1.7. The "case-only rename on Windows" problem was fixed in issue https://issues.apache.org/jira/browse/SVN-3702 (I think this fix also applies to case-insensitive filesystems on MacOS, though I have not tested that (but then again, perhaps case-insensitive filesystems on MacOS are not widely used anymore)). I'd say: let's close SVN-667 as "resolved", and add an issue link to SVN-3702. > SVN-3694 SWIG bindings, tempfiles cleanup > A script in Perl is using SWIG bindings. Filed in 2010 and there is a comment > by Roderich Schupp in 2015 "This is not a bug, it's a user error" suggesting > to that it is based on incorrect understanding of the SVN pools. According to > my test, I can reproduce the original issue but if I update the script > according to Roderich Schupp' suggestion, the error goes away. > * Close as Invalid +1 > SVN-3398 Seg fault with BDB repos > Close, since BDB is deprecated since Subversion 1.8. > * Close as Won't fix +1 > SVN-3494 moving a branch stumps svnmerge.py > Very sparse on details. No mentioning of the mailing list (but I didn't > search the archives. > * Close as Invalid +1, or as "won't fix", because svnmerge.py is part of contrib, and contrib is not supported anymore (not by the Subversion community anyway) -- and in any case svnmerge.py is deprecated I think. IIRC, svnmerge.py was a script that did some form of merge tracking, before the core implementation arrived in Subverison 1.5. Out of curiosity I've taken a quick look in its documentation: the README (https://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svnmerge/svnmerge.README) refers to a wiki page that still exists: https://www.orcaware.com/svn/wiki/Svnmerge.py. That page contains a FAQ entry: [[[ How do I migrate from svnmerge.py to Subversion 1.5's Merge Tracking? Use svnmerge-migrate-history.py to convert the merge history written by svnmerge.py into Subversion 1.5's format. ]]] In any case I think it's pretty OK to close all outstanding issues about svnmerge.py. > SVN-2802 Tests failing to cleanup bdb repositories over ra_neon > BDB and Neon are both deprecated. > * Close as Won't fix +1 > * SVN-3276 Access violation (svn move, using some java client) > Reported in 2008 on 1.5.x and there is a comment that it is not directly > using the javahl bindings but a higher level client. Nothing happened since > 2010. > * Close as Invalid +1 > * SVN-2635 svnsync pre-revprop-change hook failed > An error occured when using a batch file as pre-revprop-change hook script. > Problem went away when using a compiled program. Lesson learned: Write proper > scripts. > * Close as Invalid +0. I'm not sure about this one (maybe as "cannot reproduce", but I haven't tried to reproduce it myself). I think using BAT for hook scripts on Windows should be fine in general, so it's not clear to me why this failed. But it's oh so fragile and difficult. Maybe there is some quoting issue or something similar. Hard to say. Perhaps, to be able to make the decision for closing it with "cannot reproduce", someone might need to try the example the user gave in: https://issues.apache.org/jira/browse/SVN-2635?focusedCommentId=14923562&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14923562 > * SVN-3534 Failed ra_neon commit without --no-unlock results in dead lock > token. > ra_neon deprecated > * Close as Won't fix +1 Cheers, -- Johan
