> From: Vincent Starre [mailto:email@example.com]
The first two points look sound to me.
> third: I should be allowed to commit a file with
> mixed-line-ending-types. This would probably involve adding new
> eol-styles, such as:
I don't see what these gain you over and above leaving svn:eol-style unset.
The whole point of the "CR", "LF", and "CRLF" values is to enforce/check a
particular style on a file. It strikes me as rare that these other
combinations are needed in practice. (And you left off several
possibilities, including "CRLF-ignore-lone-CR-remove-lone-LF", for
> fourth, and obviously not a real issue: why no explicite "binary"
> eol-style? Sure, it's not needed, but I was thinking along the lines of
> "make a cmmit hook that disallows commits of files without an eol-style,
> but then there's one file that really is binary and really does need to
> be named like that"
Is no-value insufficient?
You can cross-check it with svn:mime-type -- any type that starts with
"text/" is required to have an svn:eol-style. In our code base, we have a
"In order to ensure that files checked out from the repository have the
correct end-of-line characters for the platform onto which they are checked
out, every file in the respository must have the appropriate values for the
Subversion properties svn:mime-type and/or svn:eol-style.
"All "binary" files in the repository should have a valid, non-text MIME
media type specified for their svn:mime-type property. (If no other type is
suitable, "application/octet-stream" can be used.)
"All text files must have a "text/*" svn:mime-type property, and an
svn:eol-style property. Most text files are relevant to all platforms, and
should have the value "native" for the svn:eol-style property. This ensures
that a Subversion checkout will use the right end-of-line characters for the
host operating system."
And we have a script to enforce the rule:
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Jul 20 16:14:48 2005