I've been using the mono-repo [ http://llvm.org/docs/GettingStarted.html#for-developers-to-work-with-a-git-monorepo] and this morning I ran into an issue where I am unable to submit using the mono repo. I traced this down to the fact that many files explicitly have the property svn:eol-style set to native. On the git side, we have core.autocrlf=false, which means that git will checkout as-is, commit as-is. So if a file has LF endings in the repo, git will check it out with LF line endings, and then on Windows, the local SVN clone will check out according to the value of the property, which will be CRLF. Then `git llvm push` won't be able to apply the patch to the local svn repo. It seems to me the correct thing to do is remove the `svn:eol-style` recursively from all of SVN. As it stands now, it is not even consistently applied. About half of files have it, and half of files don't. I was going to just delete the property myself from the affected files, but it turns out there are quite a few. D:\src\llvm-mono\.git\llvm-upstream-svn>svn propget -R svn:eol-style | wc -l 3460 Can I run the command `svn propdel -R svn:eol-style` on the SVN repo? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170221/739563c2/attachment.html>
Michael Kuperstein via llvm-dev
2017-Feb-22 00:41 UTC
[llvm-dev] Problem with svn:eol-style
How hard will this break people who have outstanding local changes? That is, do you know if SVN can actually handle the merge gracefully? On Tue, Feb 21, 2017 at 10:28 AM, Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote:> I've been using the mono-repo [http://llvm.org/docs/ > GettingStarted.html#for-developers-to-work-with-a-git-monorepo] and this > morning I ran into an issue where I am unable to submit using the mono > repo. I traced this down to the fact that many files explicitly have the > property svn:eol-style set to native. On the git side, we have > core.autocrlf=false, which means that git will checkout as-is, commit > as-is. So if a file has LF endings in the repo, git will check it out with > LF line endings, and then on Windows, the local SVN clone will check out > according to the value of the property, which will be CRLF. Then `git llvm > push` won't be able to apply the patch to the local svn repo. > > It seems to me the correct thing to do is remove the `svn:eol-style` > recursively from all of SVN. As it stands now, it is not even consistently > applied. About half of files have it, and half of files don't. I was > going to just delete the property myself from the affected files, but it > turns out there are quite a few. > > D:\src\llvm-mono\.git\llvm-upstream-svn>svn propget -R svn:eol-style | wc > -l > 3460 > > Can I run the command `svn propdel -R svn:eol-style` on the SVN repo? > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170221/9491bdc6/attachment.html>
If you have outstanding local changes on a non-Windows platform, you would not be affected (because eol-style:native is already LF for you). So this only affects people on Windows. If you are on Windows and you are using git, you should already have core.autocrlf=false (since it is the officially supported configuration), so this also would not affect you as any change you are working on locally would already be using LF line endings If you are on Windows and you are using SVN, this would probably affect you, but I think the number of such people might be close to 0, if not actually 0. For now, I've only changed the 2 affected files that were blocking me. This doesn't address the inconsistency in the repository in that about 80% of the files have svn:eol-style unset and the other 20% have it set. I'll wait to see if I start running into this more often. Hopefully we can get off of SVN and onto github before this becomes too much of a hassle and the problem will solve itself. On Tue, Feb 21, 2017 at 4:42 PM Michael Kuperstein <mkuper at google.com> wrote:> How hard will this break people who have outstanding local changes? > That is, do you know if SVN can actually handle the merge gracefully? > > On Tue, Feb 21, 2017 at 10:28 AM, Zachary Turner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > I've been using the mono-repo [ > http://llvm.org/docs/GettingStarted.html#for-developers-to-work-with-a-git-monorepo] > and this morning I ran into an issue where I am unable to submit using the > mono repo. I traced this down to the fact that many files explicitly have > the property svn:eol-style set to native. On the git side, we have > core.autocrlf=false, which means that git will checkout as-is, commit > as-is. So if a file has LF endings in the repo, git will check it out with > LF line endings, and then on Windows, the local SVN clone will check out > according to the value of the property, which will be CRLF. Then `git llvm > push` won't be able to apply the patch to the local svn repo. > > It seems to me the correct thing to do is remove the `svn:eol-style` > recursively from all of SVN. As it stands now, it is not even consistently > applied. About half of files have it, and half of files don't. I was > going to just delete the property myself from the affected files, but it > turns out there are quite a few. > > D:\src\llvm-mono\.git\llvm-upstream-svn>svn propget -R svn:eol-style | wc > -l > 3460 > > Can I run the command `svn propdel -R svn:eol-style` on the SVN repo? > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170222/7298e4d2/attachment.html>