[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Coding system for output of "svn cat"

From: Andre Colomb <acolomb_at_schickhardt.org>
Date: Mon, 27 Aug 2012 15:53:40 +0200

Daniel Shahaf <d.s_at_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 <acolomb_at_schickhardt.org>

Received on 2012-08-27 15:54:19 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.