Re: Jira issues cleanup

[Johan Corveleyn <jc...@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
<da...@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 <ha...@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

Re: Jira issues cleanup

[Nathan Hartman <ha...@gmail.com>]

On Tue, Jan 11, 2022 at 4:13 PM Daniel Sahlberg
<da...@gmail.com> wrote:
>> > * 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.


It might be a good idea to comment to that effect in the issue, so it
isn't forgotten. Do you still have the link to the dev@ thread?

Thanks for doing all of these!

Nathan

Re: Jira issues cleanup

[Daniel Sahlberg <da...@gmail.com>]

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 <jc...@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
> <da...@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