llvm dev - Feb 2017 - Problem with svn:eol-style

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>

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>