Idea for dealing with text-file line endings

The Zope project is in the process of adopting subversion. One
problem that we've run into is subversion's default behavior with
respect to text-file line endings. The Zope project has a combination
of Linux/Unix and Windows developers. Many of the windows developers
use tools that don't understand Unix line endings. Even the tools that
do understand Unix line endings use DOS line endings for new files.

By default, subversion doesn't do any end-of-line translation when
checking files in or out. There is a property, svn:eol-style, that can
be set to do end-of-line translation, but this property isn't set by
default. We want to arrange for end-of-line translation to be done
for all text files. We need this to be automated. This is a big issue
for us.

The recommended way to do this is to put following like the following
in each user's config file:

   [miscellany]
   enable-auto-props = yes

   [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

   ...

We find this approach unsatisfactory for two reasons:

- It is burdensome. Every developer (including people using public
   checkouts on windows) needs to have these settings.

- It is unreliable. If we forget some file pattern, we'll fail to get
   the eol-style property set.

- It is unmaintainable. Every time someone uses a new file name style
   (file extension), all of the developers need to update their
   configuration files.

We've discovered a much simpler approach that currently does much of
what we want. We simply ask all developers to have the following in
their configuration files:

   [miscellany]
   enable-auto-props = yes

   [auto-props]
   * = svn:eol-style=native

With this setting, all new files except files that svn recognizes as
binary get the svn:eol-style property set to "native", as desired.
This is great. :)

There are two disadvantages:

- It is burdensome. Every developer (including people using public
   checkouts on windows) needs to have these settings, however, it
   isn't nearly as burdensome as the recommended settings. It's a pretty
   straightforward setting. I think we can live with this.

- If I add or import a binary file, like an image, I get an error:

     $ svn add myimage.gif
     svn: File 'myimage.gif' has binary mime type property

   But the add actually works:

     $ svn status myimage.gif
     A myimage.gif

   This appears to be because the property is set after the file is
   added.

   If I add multiple files, some of which are binary:

     $ svn add text1 image1.gif text2 image2.gif
     A text1
     svn: File 'image1.gif' has binary mime type property

   I get the error after the first binary file is added, and none of
   the following files are added:

     $ svn status text1 image1.gif text2 image2.gif
     A text1
     A image1.gif
     ? text2
     ? image2.gif

   The error is annoying, but causing multi-file additions to partially
   fail is *really* problematic.

So, I have two questions. First, does this basic approach seem reasonable?
The only alternative I see is to write a post-commit script that sets
properties. This is what I planned to do until someone thought of this
idea.

If this idea does seem reasonable, can the current behavior of svn be
changed so that a warning is issued, rather than an error, when a
binary file is added? For example:

     $ svn add text1 image1.gif text2 image2.gif
     A text1
     A (bin) image1.gif
     svn: File 'image1.gif' has binary mime type property, so not
     setting svn:eol-style
     A text2
     A (bin) image2.gif
     svn: File 'image2.gif' has binary mime type property, so not
     setting svn:eol-style

     $ svn status text1 image1.gif text2 image2.gif
     A text1
     A image1.gif
     A text2
     A image2.gif

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org