Kevin Ballard wrote:

There are a ton of files in the dports tree that have svn:eol-style set to native. In theory this would be a good thing, yes? Unfortunately, it's actually not.

In the specific case of patchfiles (by far the most common type of file in the files/ directories), line endings cannot be modified or the patch utility will refuse to apply the chunks. In the more general case of anything in the files/ directories, I would assume that these files all were meant to work with their original line endings, and that, depending on the type of file in there, flipping the line endings could cause issues. The only type of file in which one could make a case for native line endings is *.txt files (of which there are a small handful).

As for the Portfiles themselves, I assume Tcl doesn't care about line endings, so I see no problem with native eol-style on those.

Does anybody have any objects to my removal of svn:eol-style on all files in the files/* directories (with the possible exception of *.txt files)?

Where specifically are you seeing a problem with this? I noticed that there are Python files that you would still want a native eol-style on, and presumable other scripts. I would be more conservative and just do a svn propdel svn:eol-style */*/files/patch* I just tried this and this modified 1830 files, so I'm a little concerned this may break something. Why not just remove the eol-style on files that have a broken build? Regards, Blair -- Blair Zajac, Ph.D. <blair@orcaware.com> http://www.orcaware.com/svn/

Why would you care about the eol style for python files? On Jan 24, 2007, at 12:35 PM, Blair Zajac wrote:

I noticed that there are Python files that you would still want a native eol-style on, and presumable other scripts.

-- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com

Kevin Ballard wrote:

I'm not seeing a problem right now, because all of the current patchfiles are supposed to have unix line endings.

But some time ago there was a problem - a patchfile I submitted had mixed line endings, and the committer converted it to unix and added svn:eol-style, which promptly broke the build. That change had to be reverted.

The simple fact is, the endline style on patchfiles is explicit and should not be touched, therefore svn:eol-style is completely wrong on patchfiles.

I agree.

The glob pattern you have there is going to miss a bunch of patchfiles. If you do it right, you end up getting... actually, I don't know the exact count. But I know there are 200-something files which *don't* match. And those are generally things like apache config files (in the case of php), shell scripts, etc. Basically, things which either don't care about line endings or will want unix line endings.

I do want svn:eol-style set on those in case somebody checks out a working copy on Windows, modifies those files and checks them back in. That would introduce CRLFs into them and gratuitous diffs. I'm of the mind that mostly everything should have svn:eol-style set except for those files that shouldn't have it, such as the patch files.

There's 5 .txt files (actually 7, but 2 are actually patches of .txt files), which are the only files I can definitively say don't care about line endings. Those are also the only files in which there's a real good reason to have native line endings.

Which are those?

And actually, I can tell you right now that removing svn:eol-style will *not* break anything. If it works with svn:eol-style, it will work without svn:eol-style. On the other hand, things that work without svn:eol-style don't necessarily work with it. And in fact if you were to try and use MacPorts on Windows (I have no idea how you'd go about doing that outside of cygwin, and it'd have to be outside of cygwin for this to matter since, IIRC, cygwin uses unix line endings) then I'd expect a lot of stuff (in fact, every single port that has a patchfile with svn:eol-style set) to break.

The real issue here isn't that svn:eol-style is breaking builds, because it's not (since everybody's building on a system with unix line endings anyway). The issue is that svn:eol-style isn't appropriate for the vast majority of files on which it's currently set. It's not causing a problem, but that doesn't mean it belongs.

Right, it's not appropriate for the patch files. For non-patch files, it is appropriate and I would rather leave them on. So that's why I suggested my glob, to remove it from patches and leave it on everything else.

What I want to do is remove svn:eol-style from all files in the files/ directories and re-add it to the 5 *.txt files (ignoring the 2 patchfiles ending in *.txt). It's been suggested that maybe we should add it to the Portfiles as well, but I don't think that particularly matters (some have it set right now and some don't - a case could be made to standardize that).

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. Granted your pass is less work, but it results in a less correct repository. I did a pass through Portfiles a while ago to set it on every Portfile. Regards, Blair

On 24 Jan 2007, at 16:06, Blair Zajac wrote:

Kevin Ballard wrote:

...

I'm not seeing a problem right now, because all of the current patchfiles are supposed to have unix line endings. But some time ago there was a problem - a patchfile I submitted had mixed line endings, and the committer converted it to unix and added svn:eol-style, which promptly broke the build. That change had to be reverted. The simple fact is, the endline style on patchfiles is explicit and should not be touched, therefore svn:eol-style is completely wrong on patchfiles.

I agree.

...

The glob pattern you have there is going to miss a bunch of patchfiles. If you do it right, you end up getting... actually, I don't know the exact count. But I know there are 200-something files which *don't* match. And those are generally things like apache config files (in the case of php), shell scripts, etc. Basically, things which either don't care about line endings or will want unix line endings.

I do want svn:eol-style set on those in case somebody checks out a working copy on Windows, modifies those files and checks them back in. That would introduce CRLFs into them and gratuitous diffs.

I'm of the mind that mostly everything should have svn:eol-style set except for those files that shouldn't have it, such as the patch files.

...

There's 5 .txt files (actually 7, but 2 are actually patches of .txt files), which are the only files I can definitively say don't care about line endings. Those are also the only files in which there's a real good reason to have native line endings.

Which are those?

...

And actually, I can tell you right now that removing svn:eol-style will *not* break anything. If it works with svn:eol-style, it will work without svn:eol-style. On the other hand, things that work without svn:eol-style don't necessarily work with it. And in fact if you were to try and use MacPorts on Windows (I have no idea how you'd go about doing that outside of cygwin, and it'd have to be outside of cygwin for this to matter since, IIRC, cygwin uses unix line endings) then I'd expect a lot of stuff (in fact, every single port that has a patchfile with svn:eol-style set) to break. The real issue here isn't that svn:eol-style is breaking builds, because it's not (since everybody's building on a system with unix line endings anyway). The issue is that svn:eol-style isn't appropriate for the vast majority of files on which it's currently set. It's not causing a problem, but that doesn't mean it belongs.

Right, it's not appropriate for the patch files. For non-patch files, it is appropriate and I would rather leave them on. So that's why I suggested my glob, to remove it from patches and leave it on everything else.

...

What I want to do is remove svn:eol-style from all files in the files/ directories and re-add it to the 5 *.txt files (ignoring the 2 patchfiles ending in *.txt). It's been suggested that maybe we should add it to the Portfiles as well, but I don't think that particularly matters (some have it set right now and some don't - a case could be made to standardize that).

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.

Granted your pass is less work, but it results in a less correct repository.

I did a pass through Portfiles a while ago to set it on every Portfile.

Regards, Blair _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev

Randall Wood rhwood@mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."

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

On Jan 25, 2007, at 02:26, Randall Wood wrote:

I have seen no standard that states how patch files are to be named

I have: http://darwinports.opendarwin.org/docs/ch04s07.html "The standard convention is to name the patch file 'patch- <filename>.diff, with one diff file per file altered in the source. If the filename is ambiguous because there are multiple files with that name in the distribution, supply the path components to uniquely identify the file being patched." I have been following this standard.

On Jan 24, 2007, at 11:35, Blair Zajac wrote:

Why not just remove the eol-style on files that have a broken build?

Note that this by itself would not be effective. Setting svn:eol- style to any value causes Subversion to convert the file to LF line endings internally when storing it in the repository. If this were to have broken any build, removing the svn:eol-style property would do just that; it would not also convert the line endings back to what they originally were, because Subversion does not know what they originally were.