Hi
I just found the eLua coding style guidelines, which say: 3. line terminators: THIS IS IMPORTANT! Use UNIX style (LF) line terminators, not DOS (CR/LF) or old Mac (CR) line terminators. but the eLua source tree has a mixture of files with LF and with CRLF line terminators. Since this seems to be the reason my previous patches appied cleanly in some environments and not in others, I wonder if it might be time to run a script to sanitize all the elua source files, or whether that might cause problems if people have large patch sets in the pipeline. I'd guess it needs to be done at some point... You can get a list of affected text files using find . \( -name .svn -prune \) -o -type f | egrep -v '\.(gif|png|jpg|bin)' | xargs grep -l '^M' (where ^M is a real control character obtained by the sequence control-V control-M) I also notice that this also lists src/platform/stm32/FWLib/.sconsign.dblite which is probably in the svn repository by mistake cheers M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
Hi Martin,
On Thu, Aug 12, 2010 at 2:06 PM, Martin Guy <[hidden email]> wrote: > Hi > I just found the eLua coding style guidelines, which say: > > 3. line terminators: THIS IS IMPORTANT! Use UNIX style (LF) line > terminators, not DOS (CR/LF) or old Mac (CR) line terminators. > > but the eLua source tree has a mixture of files with LF and with CRLF > line terminators. Thank you very much for your reports. Yes, this happens a lot, mostly when importend 3rd party files (for example support libraries) into the eLua repository. > Since this seems to be the reason my previous patches appied cleanly > in some environments and not in others, I wonder if it might be time > to run a script to sanitize all the elua source files, or whether that > might cause problems if people have large patch sets in the pipeline. > I'd guess it needs to be done at some point... I do the kind of cleaning you mention below (NL translations) from time to time, but not all the time, so accidents happen. Thanks for reminding me that it needs to be done again. > You can get a list of affected text files using > find . \( -name .svn -prune \) -o -type f | egrep -v > '\.(gif|png|jpg|bin)' | xargs grep -l '^M' > (where ^M is a real control character obtained by the sequence > control-V control-M) > > I also notice that this also lists > src/platform/stm32/FWLib/.sconsign.dblite > which is probably in the svn repository by mistake Definitely. Thanks. Best, Bogdan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
Ryan Pusztai |
On Thu, Aug 12, 2010 at 7:10 AM, Bogdan Marinescu <[hidden email]> wrote: -- Hi Martin, Why not use the SVN property 'svn:eol-style' and set it to "native". Regards, Ryan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
> Why not use the SVN property 'svn:eol-style' and set it to "native".
Mostly because I didn't know it exists :) Thanks, it looks as the right solution for this problem. I vaguely remember using something similar in CVS that caused a lot of headache, but I believe SVN can handle this much better (mostly because it can differentiate between text and binary files automatically). Thanks, Bogdan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
Dado Sutter |
In reply to this post by Ryan Pusztai
On Thu, Aug 12, 2010 at 12:36, Ryan Pusztai <[hidden email]> wrote:
Nice ! -- Thank you guys for the report (and fix :) Best Dado
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
Apparently this property can be used in conjunction with pattern
matching for filetypes: http://discuss.joyent.com/viewtopic.php?id=4612 I am, however, wondering what this does if, say, a file ends up having mixed linebreaks which I believe I've seen in the past depending on the text editor. According to the SVN docs, it will normalize everything actually in the repository to have LF (Unix) line endings, and will replace these on files that it considers to be human readable (diffable) if that's appropriate for the platform. I'm not sure what implications this will have for patches though. It may mean that one would have to apply a patch on the same platform as where the checkout was done? On Thu, Aug 12, 2010 at 12:04 PM, Dado Sutter <[hidden email]> wrote: > > > On Thu, Aug 12, 2010 at 12:36, Ryan Pusztai <[hidden email]> wrote: >> >> ................ >> Why not use the SVN property 'svn:eol-style' and set it to "native". > > Nice ! > >> >> -- >> Regards, >> Ryan > > Thank you guys for the report (and fix :) > Best > Dado > > >> >> _______________________________________________ >> eLua-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/elua-dev >> > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > -- James Snyder Biomedical Engineering Northwestern University [hidden email] PGP: http://fanplastic.org/key.txt Phone: (847) 448-0386 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
Additional note: there's a similar configurable option for Git as well:
http://help.github.com/dealing-with-lineendings/ On Thu, Aug 12, 2010 at 2:54 PM, James Snyder <[hidden email]> wrote: > Apparently this property can be used in conjunction with pattern > matching for filetypes: > http://discuss.joyent.com/viewtopic.php?id=4612 > > I am, however, wondering what this does if, say, a file ends up having > mixed linebreaks which I believe I've seen in the past depending on > the text editor. > > According to the SVN docs, it will normalize everything actually in > the repository to have LF (Unix) line endings, and will replace these > on files that it considers to be human readable (diffable) if that's > appropriate for the platform. > > I'm not sure what implications this will have for patches though. It > may mean that one would have to apply a patch on the same platform as > where the checkout was done? > > On Thu, Aug 12, 2010 at 12:04 PM, Dado Sutter <[hidden email]> wrote: >> >> >> On Thu, Aug 12, 2010 at 12:36, Ryan Pusztai <[hidden email]> wrote: >>> >>> ................ >>> Why not use the SVN property 'svn:eol-style' and set it to "native". >> >> Nice ! >> >>> >>> -- >>> Regards, >>> Ryan >> >> Thank you guys for the report (and fix :) >> Best >> Dado >> >> >>> >>> _______________________________________________ >>> eLua-dev mailing list >>> [hidden email] >>> https://lists.berlios.de/mailman/listinfo/elua-dev >>> >> >> >> _______________________________________________ >> eLua-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/elua-dev >> >> > > > > -- > James Snyder > Biomedical Engineering > Northwestern University > [hidden email] > PGP: http://fanplastic.org/key.txt > Phone: (847) 448-0386 > -- James Snyder Biomedical Engineering Northwestern University [hidden email] PGP: http://fanplastic.org/key.txt Phone: (847) 448-0386 _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
Ryan Pusztai |
In reply to this post by jbsnyder
On Thu, Aug 12, 2010 at 3:54 PM, James Snyder <[hidden email]> wrote: -- Apparently this property can be used in conjunction with pattern SVN gives the "commiter" an error about inconsistent line-ending. According to the SVN docs, it will normalize everything actually in I think you can make patch ignore line endings. If this is not what you want just force the eol-style to "LF" like the coding standard has. But in my experience "native" is clean and works very well. I think you are thinking about it because other VCS have not handled EOL well. I have not had any issues using SVN and "native".
Regards, Ryan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
Free forum by Nabble | Edit this page |