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).

While I agree that it would be nice to fix relnotes.py, it seems to me
that setting svn:eol-style=native should fix the problem completely.
Files with this attribute set are stored internally by subversion with
all newlines as LF, and converted to CRLF as needed.  After all,
eol-style=native would not be very useful if it only applied on
checkout.  Windows users would be constantly checking in CRLF in that
case.

I'm not an svn expert, though, and I haven't tested the above.

Colin


>
>
> 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/
>> >>> >
>> >>>
>>

Reply via email to