On Sun, Nov 13, 2011 at 8:46 AM, Nico Kadel-Garcia <nka...@gmail.com> wrote: [...] > No, it happens *every time* yous set it to "native" and wind up > editing code in one OS and running it in another. It's particularly a > problem when people use TortoiseSVN to a CIFS accessible for code or > documents that get run on a distinct OS. For scripting languages it's > particularly adventuresome. The replication and addition of a file > other than with 'svn copy' requires manual or semi-automated setting > of "svn:eol", or the new files will have a distinct configuraiton. > Then when you *change* them to match, diffs get complicated. > > The whole thing is better dealt with by following git's model. "Don't > touch the bytes once submitted, what comes out is byte-for-byte what > you put in". I can see uses for 'Id' and 'URL', but this end-of-line > confusion is just that far too often: confusion.
As I said already in another thread: we have no problem at all with the eol-style=native feature. We are very happy with it. Of course, we don't use working copies shared accross different OS's. As long as you understand what you're going to get with this feature, I see no problem with it. Besides, it's easy to block use of this feature, just disallow setting the eol-style property in your pre-commit hook. Then you'll get the same byte-for-byte behavior as what you're advocating. -- Johan
