Having read the "line endings with 0.31" thread and having used the
svn:eol-style property I have a vague feeling that line endings may be
better specified using some aspect of the (yet to be defined) project
policy stuff.
In an svn project that I work on, we generally set svn:eol-style to LF
for .sh files (otherwise "#! /bin/bash" ends up being "#! /bin/bash\r"
on windows and don't run on cygwin). The problem with this is that every
time someone adds a new shell script they have to remember to set the
eol-style, or some other unlucky person gets to find this bug and fix
it. This happens over and over again.
Similarly, for .c files it can be painful to watch people fighting over
line endings. One commit is CRLF, the next is LF, back and forth it
goes. This must greatly reduce repository compression and does render
diff(1) more or less useless, as often every line in the file has changed.
Subversion has something called "autoprops" which allows you to specify
which properties to set based on file name patterns, so that when new
files are added they can be assigned the correct eol-style property.
However, this is an unversioned client side setting that every committer
must have set correctly and must keep up to date. In practice this
doesn't scale to even moderately sized teams. In monotone this would be
like having the setting in a lua hook and expecting everyone on the team
to have the same hook.
So, would this be better as a (shared and versioned) project policy
entry with line ending styles specified by file name patterns. It seems
like it would handle the case of added files, that match some policy
pattern, better. I'm not sure how policy *changes* would work though.
i.e. suppose the eol policy for .sh files is set to LF after a few .sh
files have already been added incorrectly. How do the pre-existing files
get fixed up?