Julian Foad wrote:
> Stefan Kueng wrote:
>> Another reason to store whole files: patches don't work with non-text
>> files. Which is a major problem especially on Windows where files often
>> are encoded in utf16.
>
> Making 'svn diff' and 'svn patch' support non-text files is already a
> dependency of shelving-by-patch-files.
See the "Existing Issues to Overcome" section,
https://docs.google.com/document/d/1PVgw0BdPF7v67oxIK7B_Yjmr3p28ojabP5N1PfZTsHk/edit#heading=h.4sj99cgksge9
> At present, 'svn diff --git' supports non-text files by writing into the
> patch file (and encoded into ASCII), the whole of the old file and the
> whole of the new file. So that already does what you are asking: it
> 'stores whole files'. And 'svn patch' handles this as input. Just like
> 'svn merge', it chooses either one side change or the other, and if both
> sides changed that is a conflict. (I haven't tested it, I assume it
> works like that.)
Which implies that binary file support might "just work" if I simply add
the "--git" option in to the "diff" call in the prototype. I plan to try
that.
And before anyone raises their hand to say this design will be too slow
for use cases involving very large binary files, yes, I know, it almost
certainly will be. This is called a prototype for good reason.
- Julian
> Storing whole files will not magically make merging UTF-16 text changes
> work. For that, the merge will need to be taught how to process UTF-16
> text. And if we do that, then 'svn diff' and 'svn patch' could process
> UTF-16 as text too. That would be a great enhancement to Subversion, but
> is an orthogonal issue.
Received on 2017-09-02 22:28:48 CEST