gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Subversion problems on windows


From: Richard Frith-Macdonald
Subject: Re: Subversion problems on windows
Date: Wed, 8 Feb 2006 13:43:16 +0000

On 8 Feb 2006, at 13:14, Andrew Ruder wrote:

On Wed, Feb 08, 2006 at 12:41:43PM +0000, Richard Frith-Macdonald wrote:
Mostly this is just a bit annoying (you get a '^M' showing at the end
of each line when editing source code in vi), but it screws up data
files so they don't work.  Any idea how to fix this?
Yes.  The svn:eol-native property needs to be removed from the  
files.  I
can do this, but I am curious which data files it is messing up?
I noticed it in the testsuite for the base library ... it caused one  
of the GSMime tests to fail and one of the property list tests to  
fail.  The property list issues was the worrying one ... it broke  
because the property list was in unicode (16bit) characters and  
subversion had converted the two-byte character 0x000a to three bytes  
0x00 0x0d 0x0a.  I would expect that to render any unicode property  
lists and other unicode text files unusable on windows.
  But
if none of the files need this property (I was under the impression it
was standard operation with CVS), I will go through and remove them all.
I don't know if it was standard under CVS ... if it was I must have  
found a way to prevent it happeneing long ago, and then forgotten  
about it.
My understanding of the svn docs is that individual users can specify  
(based on file extension) default rules about which files use  
'native' line termination if no property is specified in the  
respository.  If that's the case, it would make sense to me to have  
no properties specifying conversion in the repository, so users can  
set up their own personal rules.
However, as you know, I'm not very familiar with subversion, so it  
might be best to hold off a little while before changing anything in  
case someone more knowledgable says this is a bad idea.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]