Why not just enforce auto-props with a hook script that sets the right properties

Is there a reason why I shouldn't take check-mime-type.pl a step further and
have my hook script set properties on newly added files according to a
repository wide policy?

 I haven't seen anyone do this and I'm wondering what the reasons might be.
Most scripts seem to reject the commit instead of warning the user with a
nag-email and then performing the property settings automatically.
*
Rational:*
- files are added less often than they are modified
- forcing all users to modify their config to enable auto-props or set
defaults is difficult when there are 80+ users one many different
platforms/machines
*
Plan:*
- All generic source files get eol-style set to native (cpp, java)
- All win specific source files get eol-style set to CRLF (.bat)
- All unix specific source files get eol-style set to LF (.sh)
- All binary files get needs-lock set to true (.jar)

The hook script would scan in the incoming commits. If the commit had text
files without eol-style set or binary files without needs-lock set, the the
script would:
- checkout the files
- update the properties
- commit the change with a useful comment "builder:r#### properties set
eol-style..."

*Problems with this Approach:*
- it shields the users from two issues they should understand (newline and
binaries)
- if there are exceptions how should the script clean up
- if there is a conflict how should the script deal with that (in theory the
hook used should prevent this)

It seems to make sense but..... Rejecting a commit with a meaningful
message is probably better. It is better to guide and train proper behavior
than making things too "easy". I could answer the other *problems* but I
think I just convinced myself that I need to teach a user to commit properly
with a rejection script (teach a man to fish vs. give a man a fish and all
that).

-- 
Peter Kahn
citizenkahn_at_gmail.com
pkahnpie1_at_AIM
http://citizenkahn.myplaxo.com
Awareness - Intention - Action