blair at orcaware.com
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:
> 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
> 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