[Monotone-devel] line endings as project policy

[Derek Scherger]

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?

Thoughts?
Derek