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.
