Thanks for the review. More below! I'm planning to continue the review of the issue list from time to time to try to decrease the number of open issues to hopefully make the issue tracker slightly more useful.
Den tis 11 jan. 2022 kl 12:11 skrev Johan Corveleyn <jcor...@gmail.com>: > 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: > >> > SVN-4639: svn.exe causes ACCESS_VIOLATION > Closed > > SVN-667 handle file name case sensitivity edge cases > Closed and linked to SVN-3702 > > SVN-3694 SWIG bindings, tempfiles cleanup > Closed > > SVN-3398 Seg fault with BDB repos > Closed > > 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. > Thanks for the detailed investigation. Won't fix is probably a better reason. I've taken the liberty to quote you and link to this thread for context. I also closed the following: SVN-3062: svnmerge doesn't warn when permission is denied for a path SVN-3446: svnmerge.py puts a file in a conflicted state although one way hasn't changed I have *not* closed the following: SVN-3500: Characters in the log that cannot be represented in local.getdefaultlocale()[1] lead to exception SVN-3406: svnmerge fails when encountering ssh warning Both contains trivial patches, but I don't know if I want to bring them in. > SVN-2802 Tests failing to cleanup bdb repositories over ra_neon > Closed > > * SVN-3276 Access violation (svn move, using some java client) > Closed > > * 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 I'm using BAT file hooks, that works fine. Let's leave it open and I'll see if I can scratch some itch with this. > > * SVN-3534 Failed ra_neon commit without --no-unlock results in dead > lock token. > > ra_neon deprecated > > * Close as Won't fix > > +1 > After a second review, I got cold feet. Julian and Mike had a discussion on dev@ at that time and I'm not sure they ruled out this being a problem either in the wc code or something that could potentially affect Serf. Kind regards, Daniel Sahlberg
