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).
Regards,
Blair
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
