RE: svn: eol-style
Jeremias Maerki wrote: Well, for XML Files this is not a big problem usually, but for Java files it usually is. But for text files in general, native EOLs make life easier for certain people. Furthermore, I don't see any such conventions documented (which doesn't mean there's no project standard): http://xml.apache.org/fop/dev/conventions.html Within the ASF in general I see a wide-spread use of the native setting. SVN handles this whole area better than CVS. According to the official doc (several versions available at: http://svnbook.red-bean.com/) Note that Subversion actually stores the files in the repository using normalized LF EOL markers regardless of the operating system. This is basically transparent to the user, though. IOW, regardless of what operating system you run on, the line endings in the repository will always get converted to LF, automatically. The svn:eol-style affects only the checked-out version on the client. And, because the properties are stored in the repository, it affects the line-endings for all clients. The default value of native is almost always the safest way to go. However, I do set my shell-scripts to LF because I usually use a Windows client to get them, but actually run them on a Linux box. Probably would be a good idea to set DOS batch files/scripts to CRLF for the same reason. But most other things are probably best left native. HTH. Victor Mote
Re: svn: eol-style
Victor Mote wrote: Jeremias Maerki wrote: Well, for XML Files this is not a big problem usually, but for Java files it usually is. But for text files in general, native EOLs make life easier for certain people. Furthermore, I don't see any such conventions documented (which doesn't mean there's no project standard): http://xml.apache.org/fop/dev/conventions.html Within the ASF in general I see a wide-spread use of the native setting. SVN handles this whole area better than CVS. According to the official doc (several versions available at: http://svnbook.red-bean.com/) Note that Subversion actually stores the files in the repository using normalized LF EOL markers regardless of the operating system. This is basically transparent to the user, though. Hi Victor, thanks for this. I had basically come to the same conclusion, but wasn't 100% sure. I am glad you have confirmed my suspicions. Chris snip/
Re: svn: eol-style
I am also trying svn:keywords=Id. Many files have 'svn:keywords : Author Date Id Revision', but my subversion manual suggests that of those only Id is recognized, along with e.g. LastChangedDate. Id comprises all known keywords. Simon On Thu, Aug 04, 2005 at 03:52:30PM +0200, Jeremias Maerki wrote: Maybe it would make sense to enable the auto-props feature of SVN client. See the SVN config file (on Windows found in %USERPROFILE%\Application Data\Subversion\): snip/ ### Set enable-auto-props to 'yes' to enable automatic properties ### for 'svn add' and 'svn import', it defaults to 'no'. ### Automatic properties are defined in the section 'auto-props'. # enable-auto-props = yes ### Section for configuring automatic properties. ### The format of the entries is: ### file-name-pattern = propname[=value][;propname[=value]...] ### The file-name-pattern can contain wildcards (such as '*' and ### '?'). All entries which match will be applied to the file. ### Note that auto-props functionality must be enabled, which ### is typically done by setting the 'enable-auto-props' option. # [auto-props] # *.c = svn:eol-style=native # *.cpp = svn:eol-style=native # *.h = svn:eol-style=native # *.dsp = svn:eol-style=CRLF # *.dsw = svn:eol-style=CRLF # *.sh = svn:eol-style=native;svn:executable # *.txt = svn:eol-style=native # *.png = svn:mime-type=image/png # *.jpg = svn:mime-type=image/jpeg # Makefile = svn:eol-style=native I'll give it a try. On 04.08.2005 15:44:07 Jeremias Maerki wrote: Well, for XML Files this is not a big problem usually, but for Java files it usually is. But for text files in general, native EOLs make life easier for certain people. Furthermore, I don't see any such conventions documented (which doesn't mean there's no project standard): http://xml.apache.org/fop/dev/conventions.html Within the ASF in general I see a wide-spread use of the native setting. On 04.08.2005 15:37:12 Chris Bowditch wrote: fellow devs, should this really be set to native ? I just did a merge conflicts using SVN Tortoise (BTW, SVN is really superior to CVS, Im really impressed!) and it changed the line endings of CR+LF. I thought the Project standard was Unix style LF line endings. So shouldn't this setting reflect this? Chris Jeremias Maerki Jeremias Maerki -- Simon Pepping home page: http://www.leverkruid.nl