Re: [BUG] svn patch with svn:eol-style set to native

[Vincent Lefevre]

On 2022-08-15 10:06:48 -0400, Nathan Hartman wrote:
> On Sun, Aug 14, 2022 at 8:08 PM Vincent Lefevre  
> wrote:
> > printf %s "$(printf "%d\n" `seq 2 8`)" > file
> 
> One thing I don't understand about the above is why does the outer
> printf %s strip the last newline from the inner one?

It is the $(...) that strips the trailing newline(s):

  
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_03

That's why I've used that.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [BUG] svn patch with svn:eol-style set to native

[Nathan Hartman]

On Mon, Aug 15, 2022 at 10:06 AM Nathan Hartman
 wrote:
> I'll file an issue in the issue tracker...

Filed: https://issues.apache.org/jira/browse/SVN-4906

Cheers,
Nathan

Re: [BUG] svn patch with svn:eol-style set to native

[Nathan Hartman]

On Sun, Aug 14, 2022 at 8:08 PM Vincent Lefevre  wrote:
>
> About this bug:
>
> On 2022-08-14 14:11:15 -0400, Nathan Hartman wrote:
> > But applying your original patch to a clean working copy and then
> > running 'svn diff' does show it -- note the - and + of  and
> > "\ No newline at end of file" at the end of the output:
> [...]
> > That looks like a bug in SVN. This machine (the one I'm using now) has
> > 1.13.0 so I'll try this with 1.14.2 later...
>
> I can reproduce the issue with svn 1.14.2, and this is due to
> svn:eol-style being set to native.


Nice catch!

Thanks for the reproduction script.

The issue: When the file has the svn:eol-style property set and the
last line of the file does not end with a newline, 'svn patch' adds a
newline to the last line of the file, even when the diff does not call
for it.

I've confirmed that the same issue is reproduced for all possible
svn:eol-style settings. (I did that by using the reproduction script
as-is, and then also modifying it to try the other svn:eol-style
settings of CRLF, LF, and CR.)

I went through the issue tracker looking for similar issues. SVN-3556
and SVN-3991 are *not* similar, but I'm making a note of them here as
they may be relevant. In particular, SVN-3991 seems to be somewhat a
reverse of this issue, where the patch file, rather than the file
being patched, lacks a last newline.

For reference, this was found during the recent dev@s.a.o mail thread
"[PATCH] URL update to https" -- see the part starting with "Are you
sure" in 14 August 2022 message:
https://lists.apache.org/thread/w0fld2p0qzg5oo6tqgw1tcvtolndvg9t

I'll file an issue in the issue tracker...

> printf %s "$(printf "%d\n" `seq 2 8`)" > file

One thing I don't understand about the above is why does the outer
printf %s strip the last newline from the inner one?

Cheers,
Nathan

Re: Bug-Report: SVN PATCH applies lines of context instead of patch content

[Daniel Sahlberg]

Den mån 15 aug. 2022 kl 12:00 skrev Nelskamp-Lukas, Carsten <
c.nelskamp-lu...@prosoz.de>:

> Hello,
>
>
>
> steps to reproduce the issue:
>
>
>
> Given a repository file "PARKMB.csv" with content:
>
> 5
>
> 7
>
> 9
>
> [eof]
>
>
>
> and a patch file "patch.patch" with content:
>
> Index: PARKMB.csv
>
> ===
>
> --- PARKMB.csv(revision 203095)
>
> +++ PARKMB.csv (revision 203179)
>
> @@ -3,3 +3,9 @@
>
> 7
>
> 8
>
> 9
>
> +10
>
> +11
>
> +12
>
> +13
>
> +14
>
> +15
>
> [eof]
>
>
>
> The patch file is intended to apply 6 lines at the end of file
> "PARKMB.csv".
>
> Applying the patch with "> svn patch patch.patch" leads to the following
> output:
>
> U PARKMB.csv
>
> > applied hunk @@ -3,3 +3,9 @@ with offset -2 and fuzz 2
>

Gmail was stupid when trying to copy your files, but I finally got it
working. I can confirm the issue both on Windows (using TortoiseSVN built
from Subversion /trunk as of April) and on Linux (svn, version 1.14.1
(r1886195), as supplied by the Ubuntu 22.04.1 running on WSL).

 I expect the file "PARKMB.csv" to contain:
>
> 5
>
> 7
>
> 9
>
> 11
>
> 12
>
> 13
>
> 14
>
> 15
>
> 16
>
> [eof]
>
>
>
> But it contains:
>
> 5
>
> 7
>
> 9
>
> 11
>
> 12
>
> 13
>
> 14
>
> *7*
>
> *9*
>
> [eof]
>
>
>
> Four lines of the patch file have been added as expected. But the last two
> lines seem to have been replaced with the last to lines of the context of
> the patched file (7 and 9 instead of 14 and 15).
>

I suspect something is wrong with the fuzzy matching. It was originally
implemented under https://issues.apache.org/jira/browse/SVN-3460 but I
don't have the time right now to investigate if it has been updated since.

Operation System:
>
> Windows 10 Enterprise, Version 21H2, Build 19044.1826
>
>
>
> SVN installed with TortoiseSVN:
>
> svn, version 1.14.2 (r1899510)
>
>compiled Apr  9 2022, 14:18:14 on x86-microsoft-windows
>
>
>
> TortoiseSVN:
>
> TortoiseSVN 1.14.3, Build 29387 - 64 Bit , 2022/04/08 19:31:22
>
> ipv6 enabled
>
> Subversion 1.14.2, -release
>
> apr 1.6.5
>
> apr-util 1.6.1
>
> serf 1.3.9
>
> OpenSSL 1.1.1n  15 Mar 2022
>
> zlib 1.2.11
>
> SQLite 3.36.0
>

>
>
>
> Thank you for considering this issue.
>
>
>
> Regards,
>
> Carsten Nelskamp-Lukas
>

Thanks for the report!

Kind regards,
Daniel Sahlberg