svn:eol-style property

Blair Zajac blair at
Thu Jan 25 09:48:01 PST 2007

Kevin Ballard wrote:
> On Jan 25, 2007, at 3:26 AM, Randall Wood wrote:
>>> I disagree.  Take it off of the */*/patch* and the 200 other patches, 
>>> which I guess are poorly named then since they don't start with the 
>>> word patch, and leave everything else alone.
>> I have seen no standard that states how patch files are to be named - 
>> I use *.patch to name my patch files and think that is a better way to 
>> name the file. Try globbing for */*/*patch* instead.
> I created a find pattern to find all the patches earlier, but with a bit 
> of experimentation here's a bash glob pattern that works:
> */*/files/{patch{_,-}*,*.diff,*{-,.}patch,patch{es,}}
> This finds 2396 (out of 2443) files. I'll kill svn:eol-style on all of 
> these, then investigate the other 47 files by hand. If they're scripts 
> (or .txt files), ok, I'll keep svn:eol-style set on them. If they're 
> something else, well, I'll figure it out (what else might there be, I 
> wonder?)

Sounds good.

> Incidentally, for script files should I really use svn:eol-style native, 
> or should I use svn:eol-style LF? The stated reason to have it is so 
> someone on windows who edits it won't screw it up, but I assume if 
> someone on windows edits a file and converts the line endings to CRLF, 
> having it set to LF will simply fix it, no? The reason I'm proposing 
> this is because I don't know for a fact that all scripting languages 
> support windows line endings (at least, when running under a unix 
> environment). Can anybody tell me for a fact that they do?

The point for svn:eol-style native is to allow people to check out files 
and edit them on their own box and not have to worry about the end of lines.

If we set the style to LF, then people that do check the files out on 
Windows to edit will have only LFs and not CRLFs in the file and then 
notepad or other simple editors will get a file that appears to be one 
long line instead of a normal looking like file.  So svn:eol-style LF 
prevents people with Windows clients from editing our files easily.

Since we're only running the scripts on Unix OSes, or even Cygwin, then 
when we do a checkout there, the end-of-line is LF, so everything works 
fine.  Now, if we do checkouts on non-Unix OSes where the eol is not LF 
and need to run them and the script process needs LF end of lines, then 
there's an issue, but I don't see this as being a problem since we're 
very unlikely to run into it.  Even in Cygwin, most people have it run 
in LF mode, not CRLF mode.

I think you're trading a known issue that we can run into now (people 
editing these files on Windows systems and wanting to provide the 
correct system end-of-lines to make life easy) vs a problem which isn't 
occurring (running a script with CRLF on a scripting engine that needs LFs).


More information about the macports-dev mailing list