Jira issues cleanup

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

Hi,

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

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.

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.

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.

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

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

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'll follow up with further e-mails trying to identify issues that we
should close, but time is up for today.

Kind regards,
Daniel

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

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

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

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.nathan@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.


> > 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.


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?

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

SVN-3398 Seg fault with BDB repos
Close, since BDB is deprecated since Subversion 1.8.
* Close as Won't fix

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

SVN-2802 Tests failing to cleanup bdb repositories over ra_neon
BDB and Neon are both deprecated.
* Close as Won't fix

* 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

* 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

* SVN-3534 Failed ra_neon commit without --no-unlock results in dead lock
token.
ra_neon deprecated
* Close as Won't fix

Running out of time for now but I'll be back ;-)

Kind regards,
Daniel

Re: Jira issues cleanup

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

On Mon, Dec 27, 2021 at 4:52 PM Daniel Sahlberg
<da...@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