svn:eol-style property
Randall Wood
rhwood at mac.com
Thu Jan 25 00:26:55 PST 2007
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 at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo/macports-dev
Randall Wood
rhwood at mac.com
"The rules are simple: The ball is round. The game lasts 90 minutes.
All the
rest is just philosophy."
More information about the macports-dev
mailing list