Bug 96934 – Files with CRLF lineendigs without svn:eol-style=native kills git svn repositories

• Component: New Bugs
• Status: RESOLVED FIXED

[Csaba Osztrogonác]

- old change cleanup patch - https://trac.webkit.org/changeset/73060
- New vcproj files without setting svn:eol-style=native caused problem again
  https://trac.webkit.org/changeset/128771 - https://bugs.webkit.org/show_bug.cgi?id=96175

Is there a way to do it automatically? I mean a similar way to set image mime 
type for png file automatically: https://trac.webkit.org/changeset/122311
(and check-webkit-style, of course)

But pre commit hook would be the best way to avoid this kind of problems.

[Csaba Osztrogonác]

(In reply to comment #0)
> - New vcproj files without setting svn:eol-style=native caused problem again
>   https://trac.webkit.org/changeset/128771 - https://bugs.webkit.org/show_bug.cgi?id=96175

http://trac.webkit.org/changeset/128777 fixed the problem in this case. But we
need a general fix to avoid running into it again and again in the future.

[Csaba Osztrogonác]

It caused problem again - https://trac.webkit.org/changeset/136292.
I'm going to fix it manually now, but we really need the proper fix.

[Csaba Osztrogonác]

One more problematic patch - http://trac.webkit.org/changeset/138656 because of this bug. And the quick fix for it - https://trac.webkit.org/changeset/138706.

Could you guys (Apple Windows developers) pick up this bug 
to avoid this kind of problems in the future?

[Roger Fong]

So if you set 
*.vsprops = svn:eol-style=native
*.vcproj = svn:eol-style=native

in ~/.subversion/config
that should solve the line endings issue.

Not sure how to do deal with mime types yet.
I don't think you can just set

svn:mime-type = none

I'll make not of that in the Windows setup development steps

[Eric Seidel (no email)]

http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/style/checkers/png.py checks SVN settings, perhaps we need a similar check for vcproj files.

[Csaba Osztrogonác]

One more occurance - http://trac.webkit.org/changeset/140568 killed all EWS bots :-/

It would be great if somebody - who interested in Windows port - fix this bug.

[Csaba Osztrogonác]

It is P1/critical, because it causes problem regularly.

[Eric Seidel (no email)]

It seems webkit-patch land (or a real pre-commit hook?) could just fix this/block this for us?

It would also be nice if we had a project-recommended svn-config file in the repo so that at least bots could use it, even if members didn't.

[Tony Chang]

I'm confused, why should the svn:eol-style be native rather than CRLF for Windows files?

[Tony Chang]

According to aroben:

"""WebKit's .gitattributes file contains the following:

*.vcproj eol=crlf
*.vsprops eol=crlf
*.sln eol=crlf

This tells git, "When storing this file in the repository, convert all
line endings to LF. When checking out this file to disk, convert all
line endings to CRLF."

If the committed version of the file in the repository contains CRLF
line endings, git will show a diff that converts the CRLF line endings
to LF. eol=crlf means that the line endings *in the repository* should
be LF, so git is trying to fix it.

I think the thing to do is to set svn:eol-style to "native" for all
.vcproj, .vsprops, and .sln files. That way Subversion will commit the
files using LF line endings (like git wants), and check them out using
CRLF on Windows (like Visual Studio wants)."""

This feels weird to me if you use svn on Windows, you'll get the files with LFs.

[Adam Roben (:aroben)]

(In reply to comment #10)
> This feels weird to me if you use svn on Windows, you'll get the files with LFs.

You will if you use Cygwin's Subversion, which I guess is what most people use. But does Visual Studio actually care if it's LF? (I know Visual Studio will change the file to CRLF if you edit it in VS, but Subversion should handle that just fine.)

[Tony Chang]

(In reply to comment #11)
> (In reply to comment #10)
> > This feels weird to me if you use svn on Windows, you'll get the files with LFs.
> 
> You will if you use Cygwin's Subversion, which I guess is what most people use. But does Visual Studio actually care if it's LF? (I know Visual Studio will change the file to CRLF if you edit it in VS, but Subversion should handle that just fine.)

1) You checkout the file with Cygwin Subversion.  The file will be LF.
2) You edit the file in Visual Studio and save.  The file is now CRLF.
3) You run svn diff, now every line shows up as a diff now.
4) You commit the file with Cygwin Subversion.  The file goes back in as LF.

Alternately:
1) You checkout the file with Window Subversion.  The file will be CRLF.
2) You edit the file in Visual Studio and save.  The file is still CRLF.
3) You run svn diff, you only see your changes.
4) You commit the file with Windows Subversion.  The file goes back in as CRLF.

Both of these sound suboptimal.  Is there no way to set .gitattributes to work the same way as subversion?

[Tony Chang]

BTW, Chromium devs on Windows use Windows subversion.

[Adam Roben (:aroben)]

(In reply to comment #12)
> 1) You checkout the file with Cygwin Subversion.  The file will be LF.
> 2) You edit the file in Visual Studio and save.  The file is now CRLF.
> 3) You run svn diff, now every line shows up as a diff now.

Is this really true? I thought svn diff would take the svn:eol-style into account and not show you any extraneous diffs in this case.

> 4) You commit the file with Cygwin Subversion.  The file goes back in as LF.
>
> Alternately:
> 1) You checkout the file with Window Subversion.  The file will be CRLF.
> 2) You edit the file in Visual Studio and save.  The file is still CRLF.
> 3) You run svn diff, you only see your changes.
> 4) You commit the file with Windows Subversion.  The file goes back in as CRLF.
> 
> Both of these sound suboptimal.  Is there no way to set .gitattributes to work the same way as subversion?

According to http://svnbook.red-bean.com/en/1.1/ch07s02.html, in regards to svn:eol-style native:

> Note that Subversion will actually store the file in the repository using normalized LF EOL markers regardless of the operating system. This is basically transparent to the user, though.

So I think your (4) in each case is slightly wrong. "The file goes back in as LF" would be accurate according to the above.

So the Windows Subversion situation seems good to me. And Cygwin might be good; we just need to see how svn diff behaves.

Or am I missing something?

[Tony Chang]

I tested to see what Cygwin svn diff would do, and you're right, it doesn't show the line ending differences.

Ok, I am convinced that we want native line endings for these files.  I'll fix them.

[Adam Roben (:aroben)]

Yay!

[Tony Chang]

http://trac.webkit.org/changeset/142923

[Ahmad Saleem]

It landed as per Comment 17 but not marked as "RESOLVED FIXED". Marking it as "RESOLVED FIXED" now. Thanks!

[Radar WebKit Bug Importer]

<rdar://problem/98240364>