| Summary: | Files with CRLF lineendigs without svn:eol-style=native kills git svn repositories | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Csaba Osztrogonác <ossy> |
| Component: | New Bugs | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | Critical | CC: | abarth, ahmad.saleem792, alancutter, andersca, aroben, bank, bfulgham, dbates, dpranke, eric, gustavo, mark.lam, mrowe, ossy, roger_fong, tony, webkit-bug-importer, zan |
| Priority: | P1 | Keywords: | InRadar |
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
|
Description
Csaba Osztrogonác
2012-09-17 10:58:24 PDT
(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. 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. 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? 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 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. 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. It is P1/critical, because it causes problem regularly. 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. I'm confused, why should the svn:eol-style be native rather than CRLF for Windows files? 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. (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.) (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? BTW, Chromium devs on Windows use Windows subversion. (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? 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. Yay! It landed as per Comment 17 but not marked as "RESOLVED FIXED". Marking it as "RESOLVED FIXED" now. Thanks! |