On Tue, Dec 17, 2019 at 08:33:09AM -0500, Doug Robinson wrote:
> > And of course, both the
> > filename and the label (= the part after the tab character) may contain an
> > arbitrary number of spaces.
>
> The problem is parsing the line into proper tokens when every character out
> there can be part of the file name. There must be a structure to the field
> or parsing is not really parsing anymore.
The output of 'svn diff' was not designed with 'svn patch' in mind.
The diff command preceded the patch command by many years.
I still believe that making --patch-compatible produce filenames without
any trailing annotations in the output of 'svn diff' is the best answer.
This whole discussion started off with the problem statement that the
--patch-compatible option produces a diff which cannot be applied after
tabs are replaced with spaces.
This filename parsing problem isn't limited to 'svn patch'. Other patch
implementations might run into the same problem. The way 'svn patch' finds
the filename is based on Larry Wall's original patch program.
Generally, patches being mangled in transit is a notorious problem especially
with web-based email. It's not really a safe format for this purpose. If patches
get changed in transit in any way there is no guarantee they will apply cleanly.
That's not a new problem, it's a long-standing issue. And it's not SVN-specific.
There is already a way to transfer changes without such problems: svn commit
Received on 2019-12-17 14:58:28 CET