On 2/3/07, Jeff Smith <jsmith@robotronics.com> wrote:
> 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?
No, by default (e.g. without any svn:-properties set), Subversion
doesn't modify any files and treats all files as binary.
Only when instructed to translate eols, there's a special form
(normalized form or normal form) which the repository is expected to
contain. The rules are simple and optimized for 'as little translation
on the client side as possible':
svn:eol-style Normal Form
native LF
LF LF
CR CR
CRLF CRLF
> 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.
Why set the svn:eol-style properties at all in your imported vendor
branch? You could track the vendor branch without the changed eol
styles and have you own trunk contain the properties. When you merge
changes between 2 vendor imports, you need to normalize eols, but the
original eols have been recorded anyway.
bye,
Erik.
---------------------------------------------------------------------
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:17:04 2007