Daniel Shahaf <d...@daniel.shahaf.name> wrote on 2012-08-27 15:38 > Andre Colomb wrote on Mon, Aug 27, 2012 at 14:26:17 +0200: >> What is the EOL encoding of text files spit out by the svn cat command? >> Does it depend on the svn:eol-style property? >> > > I expect it will be the local EOL style if the property is set to > "native", the specified style if it's set to LF/CR/CRLF, and > byte-for-byte reproduction otherwise.
Okay, that's what I expected. > I also note that 'export' has a --native-eol option. So you could use > 'svn export $URL/to/file', or maybe teach that option to the 'svn cat' > command. That would be an option. The current code in psvn.el uses svn cat to export the contents to a buffer and then apparently _suppresses_ emacs' internal coding system detection. >> I'm trying to improve the contributed psvn.el mode and need to figure >> out how to get rid of extra ^M characters at the end of every line when >> checking out an older revision (which uses svn cat internally) and >> comparing it with the working copy. >> > > svn diff -x--ignore-eol-style > ? svn diff works fine in psvn.el when requesting a simple diff and actually uses -x --ignore-eol-style, just as you suggested. However, for conflict resolution or when using svn-status-ediff-with-revision to examine the local changes using ediff mode, it has to retreive the base version as a file or at least as buffer content. I think there is a way to force the EOL conversion in Emacs itself when loading the buffer which was filled by "svn cat". Just as it does when opening a regular file from the working copy. This must have been broken for quite some time already. But in the most common use-case, when comparing the working copy against BASE, the code path was not actually used. It opened the file from .svn/text-base/ directly, which no longer works with SVN 1.7. Retreiving a different revision with non-native EOL markers stored and no svn:eol-style property for automatic conversion, it would get saved with additional ^M endings in my case. Will let you guys know when I have a patch ready to make this work. Thanks for the clarification! André -- Greetings... From: Andre Colomb <acol...@schickhardt.org>
signature.asc
Description: OpenPGP digital signature
