BTW, I just checked in the eol fix for the releasenotes.html, so git users wouldn't be annoyed until the next relnotes.py run :)
On Sat, Jun 29, 2013 at 5:18 PM, Luke Lu <l...@vicaya.com> wrote: > The problem is due to relnotes.py generating the html containing some CRLF > (from JIRA) and the release manager not using git-svn, which caused the > html with mixed eol getting checked in. The problem would then manifest for > git users due to text=auto in .gitattributes (see HADOOP-8912) that auto > converts CRLF to LF, hence the persistent modified status of the > releasenotes.html for a fresh checkout. > > Adding svn:eol-style=native would only fix half the problem. We need to > fix relnotes.py to avoid generating html with mixed eols (by normalizing > everything to LF or native). > > > On Fri, Jun 28, 2013 at 1:03 PM, Colin McCabe <cmcc...@alumni.cmu.edu>wrote: > >> Clarification: svn:eol-style = native causes the files to contain >> whatever the native platform used to check out the code uses. I think >> just setting this property on all the HTML files should resolve this >> and future problems. >> >> patch posted. >> C. >> >> On Fri, Jun 28, 2013 at 12:56 PM, Colin McCabe <cmcc...@alumni.cmu.edu> >> wrote: >> > I think the fix for this is to set svn:eol-style to "native" on this >> > file. It's set on many other files, just not on this one: >> > >> > cmccabe@keter:~/hadoopST/trunk> svn propget svn:eol-style >> > ./hadoop-project-dist/README.txt >> > native >> > cmccabe@keter:~/hadoopST/trunk> svn propget svn:eol-style >> > ./hadoop-hdfs-project/hadoop-hdfs/src/main/docs/releasenotes.html >> > cmccabe@keter:~/hadoopST/trunk> >> > >> > It might also be a good idea to run dos2unix on it. >> > >> > I thought that in general we wanted to have 'LF' everywhere, so >> > perhaps we should add this to the patch.sh script to prevent this from >> > re-occurring. >> > >> > Colin >> > >> > >> > On Fri, Jun 28, 2013 at 12:27 PM, Sandy Ryza <sandy.r...@cloudera.com> >> wrote: >> >> I haven't been able to find a solution. Just filed >> >> https://issues.apache.org/jira/browse/HADOOP-9675. >> >> >> >> >> >> On Fri, Jun 28, 2013 at 12:19 PM, Omkar Joshi <ojo...@hortonworks.com >> >wrote: >> >> >> >>> Sandy... did you fix this? any jira to track? me too facing same >> problem.. >> >>> >> >>> Thanks, >> >>> Omkar Joshi >> >>> *Hortonworks Inc.* <http://www.hortonworks.com> >> >>> >> >>> >> >>> On Fri, Jun 28, 2013 at 11:54 AM, Zhijie Shen <zs...@hortonworks.com> >> >>> wrote: >> >>> >> >>> > Have the same problem here, have to edit the patch manually to >> exclude >> >>> the >> >>> > changes in releasenotes.html >> >>> > >> >>> > >> >>> > On Fri, Jun 28, 2013 at 11:01 AM, Sandy Ryza < >> sandy.r...@cloudera.com >> >>> > >wrote: >> >>> > >> >>> > > Has anybody else been having trouble with line endings since >> pulling >> >>> > trunk >> >>> > > recently? >> >>> > > >> >>> > > >> hadoop-common-project/hadoop-common/src/main/docs/releasenotes.html >> >>> > > shows up as modified even though I haven't touched it, and I can't >> >>> check >> >>> > it >> >>> > > out or reset to a previous version to make that go away. The only >> >>> thing >> >>> > I >> >>> > > can do to neutralize it is to put it in a dummy commit, but I >> have to >> >>> do >> >>> > > this every time I switch branches or rebase. >> >>> > > >> >>> > > This appears to have began after the release notes commit >> >>> > > (8c5676830bb176157b2dc28c48cd3dd0a9712741), and must be due to a >> line >> >>> > > endings change. >> >>> > > >> >>> > > -Sandy >> >>> > > >> >>> > >> >>> > >> >>> > >> >>> > -- >> >>> > Zhijie Shen >> >>> > Hortonworks Inc. >> >>> > http://hortonworks.com/ >> >>> > >> >>> >> > >
