Ari Jolma wrote:
I want to keep all files locally LF also in Windows. I've set
Unfortunately, I don't think SVN supports this idea. The eol-style property is set on the file, and everyone that checks it out gets that property. What this means is that it is that what it is set to is a project level decision, and my experience says that "native" is the only reasonable option for text files -- you simply can't count on editors dealing with non-native line feeds properly(even though many do), and you really get a mess if they don't.
In the menu Tortoise adds into file managers in Windows, there is a properties command, which opens a window of Property => Value data (of the file I presume). The svn:eol-style seems to be native always. I changed this to LF and the effect is just what I want. The file comes back LF even if I delete it, i.e., the property is set also in the server.
right, but that means that anyone else that checks out that file on any system is going to get LF, and if they have a stupid Windows editor or compiler, that could cause problems.
I assume I shouldn't set the property to LF for files which I don't "own" (everything else than the Perl bindings)?
The trouble is that even though you are the primary editor of the Perl bindings, others will, at the very least, check out the files and look at them or compile them. I don't think it's a good idea to have different systems for different parts of the the same project -- wouldn't it get messy for you, if no one else?
Why do you need LF on Windows? Why not just use Windows line endings on windows? With a decent editor is should be completely transparent anyway.
Ideally, your SVN client would let you define what "native" linefeeds mean to you, but I don't know that Tortoise (or any other) client supports that. You might try a feature request.
-Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
