On Friday 02 February 2007 15:01, Erik Huelsmann wrote:
> There is one and only one correct internal Normalized Form of files
> with a given svn:eol-style. Not converting brings much more trouble
> on the implementation side than it does when converting. svn needs
> to convert and this has nothing to do with the user.
>
> Since there seem to be 2 camps here and very few new arguments, can
> we please let it go now?
Thanks Erik, you've indicated something new, "correct internal
Normalized Form", so now I can hope to have an intelligent
conversation.
I'd like to understand how it stores the known text files internally
in a "Normalized Form" without modifying the file, or does that imply
it does modify text files in this case? Afterall, if it only stores
them with one EOL format, then it would not be able to export the
original file with any other eol format unless it describeds in the
repository exactly what that format used to be.
Does it automatically normalize all files it detects as straight text
(no mixed eol styles), or does it only triger this behavior if, for
instance, svn:eol-style is being set by auto-props?
Thanks, it would help me find a better approach for my apparent
long-term problem with FreeRTOS vendor releases. See, all I have so
far is to modify the line-ends before importing, which loses history
of the file changed from the vendor.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Feb 3 00:06:20 2007