You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jeff Smith <js...@robotronics.com> on 2007/02/02 23:05:37 UTC
information about storing text-only files
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
Re: information about storing text-only files
Posted by Frodak <fr...@yahoo.com>.
--- Les Mikesell <le...@gmail.com> wrote:
> Erik Huelsmann wrote:
>
> >> I would think, ideally, that it would show the
> >> property change only as it is still a text file
> and
> >> only the EOL style has changed.
> >
> > But subversion doesn't know about text files :-)
> It only knows it
> > needs to do certain transforms on special events
> in order to make sure
> > the user has the right eol style in his working
> copy. Nothing more.
>
> If that were true it wouldn't make any sense to show
> diffs as lines. If
> it understands the concept of lines it should know
> they didn't change.
> If it doesn't the diffs should only be binary byte
> differences. What
> does a line or eol style mean to something that
> doesn't know about text
> files?
Subversion can handle a lot of EOL issues. Just try
it out.
$ svn diff file:///svn/text/tags/v1
file:///svn/text/tags/v2
Index: source.txt
===================================================================
--- source.txt (.../v1) (revision 17)
+++ source.txt (.../v2) (revision 17)
@@ -5,4 +5,5 @@
This is a LF line
This is a LF line
-This is a LF line
+This is a new CRLF line
+This is a LF line
The file source.txt has no properties set and has
mixed EOLs.
Now if I merge this into the trunk which has
svn:eol-style = native it will correctly normalize the
EOLs in the new files. If I don't have svn:eol-style
set then it will not normalize the EOLs and the
working copy will have mixed EOLs.
____________________________________________________________________________________
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives.
http://tools.search.yahoo.com/toolbar/features/mail/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: information about storing text-only files
Posted by Les Mikesell <le...@gmail.com>.
Erik Huelsmann wrote:
>> I would think, ideally, that it would show the
>> property change only as it is still a text file and
>> only the EOL style has changed.
>
> But subversion doesn't know about text files :-) It only knows it
> needs to do certain transforms on special events in order to make sure
> the user has the right eol style in his working copy. Nothing more.
If that were true it wouldn't make any sense to show diffs as lines. If
it understands the concept of lines it should know they didn't change.
If it doesn't the diffs should only be binary byte differences. What
does a line or eol style mean to something that doesn't know about text
files?
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: information about storing text-only files
Posted by Erik Huelsmann <eh...@gmail.com>.
On 2/3/07, Frodak <fr...@yahoo.com> wrote:
>
> --- Erik Huelsmann <eh...@gmail.com> wrote:
>
> >
> > 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
>
> Unfortunately, this seems to be where subversion text
> handling breaks down. Once it converts from one
> Normal Form to another, the diff shows that every line
> is different.
>
> I would think, ideally, that it would show the
> property change only as it is still a text file and
> only the EOL style has changed.
But subversion doesn't know about text files :-) It only knows it
needs to do certain transforms on special events in order to make sure
the user has the right eol style in his working copy. Nothing more.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: information about storing text-only files
Posted by Frodak <fr...@yahoo.com>.
--- Jeff Smith <js...@robotronics.com> wrote:
> On Friday 02 February 2007 17:00, Erik Huelsmann
> wrote:
> [...]
> > [Frodak]> Unfortunately, this seems to be where
> subversion text
> > > handling breaks down. Once it converts from one
> > > Normal Form to another, the diff shows that
> every line
> > > is different.
> > >
> > > I would think, ideally, that it would show the
> > > property change only as it is still a text file
> and
> > > only the EOL style has changed.
>
> I'm not sure what this means because it appeared
> that svn:eol-styles
> was meant to solve the very problem where Frodak
> said it "breaks
> down"... svn has a design flaw? Do I misunderstand
> what Frodak just
> said is wrong:
>
> [example text imported with svn:eol-style=native]
> this is\r
> plain text\r
>
> [translated normalized in repository]
> this is\n
> plain text\n
>
> [check out to Win]
> this is\r\n
> plain text\r\n
>
> [now using `svn diff` shows every line changed?]
You are only looking at the working copy, and not the
normalized form that is stored in subversion.
Check out the file, and change the property from
native and CRLF. Then do a diff, and it shows that
property is different.
Then check in the file, once that happens it'll
renormalize the file.
Then do a diff between the file when it was native and
then when it was CRLF, and you'll see that every line
has changed.
So yes, I do think that this is where subversions
handling of text files breaks down. I think the
desired behavior of a diff between 2 files where the
svn:eol-style is different is to show you the change
in the property and any changes in content (but not
because the EOL changed). Like you get if you use
"diff --strip-trailing-cr" when comparing a unix file
to a dos file.
>
> > But subversion doesn't know about text files :-)
> It only knows it
> > needs to do certain transforms on special events
> in order to make
> > sure the user has the right eol style in his
> working copy. Nothing
> > more.
>
> I'll ignore that you contradict yourself, but, is
> there some
> unmentioned aspect of a "text file" that svn does
> not know about?
> We've already acknowledge that diff shows diff
> context, and that svn
> even supports svn:eol-style completely relying on
> the strict rules of
> a text file.
I'll ignore the fact I'm not the author of the above quote.
____________________________________________________________________________________
Need Mail bonding?
Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
http://answers.yahoo.com/dir/?link=list&sid=396546091
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: information about storing text-only files
Posted by Jeff Smith <js...@robotronics.com>.
On Friday 02 February 2007 17:00, Erik Huelsmann wrote:
[...]
> [Frodak]> Unfortunately, this seems to be where subversion text
> > handling breaks down. Once it converts from one
> > Normal Form to another, the diff shows that every line
> > is different.
> >
> > I would think, ideally, that it would show the
> > property change only as it is still a text file and
> > only the EOL style has changed.
I'm not sure what this means because it appeared that svn:eol-styles
was meant to solve the very problem where Frodak said it "breaks
down"... svn has a design flaw? Do I misunderstand what Frodak just
said is wrong:
[example text imported with svn:eol-style=native]
this is\r
plain text\r
[translated normalized in repository]
this is\n
plain text\n
[check out to Win]
this is\r\n
plain text\r\n
[now using `svn diff` shows every line changed?]
> But subversion doesn't know about text files :-) It only knows it
> needs to do certain transforms on special events in order to make
> sure the user has the right eol style in his working copy. Nothing
> more.
I'll ignore that you contradict yourself, but, is there some
unmentioned aspect of a "text file" that svn does not know about?
We've already acknowledge that diff shows diff context, and that svn
even supports svn:eol-style completely relying on the strict rules of
a text file.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: information about storing text-only files
Posted by Frodak <fr...@yahoo.com>.
--- Erik Huelsmann <eh...@gmail.com> wrote:
>
> 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
Unfortunately, this seems to be where subversion text
handling breaks down. Once it converts from one
Normal Form to another, the diff shows that every line
is different.
I would think, ideally, that it would show the
property change only as it is still a text file and
only the EOL style has changed.
____________________________________________________________________________________
Finding fabulous fares is fun.
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.
http://farechase.yahoo.com/promo-generic-14795097
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: information about storing text-only files
Posted by Erik Huelsmann <eh...@gmail.com>.
On 2/3/07, Jeff Smith <js...@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