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/03/02 19:47:48 UTC
So which is subversion wrong about; changing imported files
I have still found no official word on this... People who sound like
they know what they are talking about insist these points:
1. Subversion will always PRESERVE the original file when importing
(many authors)
2. Subversion doesn't have a text or binary interpretation for files,
but can "translate" between CR, LF, CRLF sequences (Erik Huelsmann)
3. Subversion must not try to use a "heuristic" approach to read a
file which is expected to be text but seems to have mixed eol-style.
This would risk changing the meaning of the file because of
ambiguousness of mixed eol-styles.
I can completely support 1, however:
The problem is that those insisting that 1 is solid have also proven
to me that when dealing with svn:eol-style (in auto-properties),
Subversion breaks the law. In the repository, it "normalizes" the
file. Read "I, Robot" by Isaac Asimov, and see that these guys are
probably calling it "normalize" instead of "modify" to save
developers from breaking down, realizing that they have actually
modified the file on import. Once imported, there is ABSOLUTELY no
indication of whether that file originally ended lines with CR, LF,
or CRLF characters. Let's face it... the file has been modified! I
would rather subversion be consistent, but preserving this file.
Contradiction 2:
This is probably not a common claim, so I should ignore it, but... The
general rule is apparently that it only is allowed to translate if it
uses a simple heuristic to detect the file as consistent text format
using only one eol-style. This rule really fortifies the fact that it
DOES "have a text or binary interpretation". What's more, obviously
it would not be able to display the famous "diff" if it did not
assign the files a "texty" value. So throw out 2.
Who can question 3:
Or rather, why have I not heard anyone else question 3? It says in
other words, "if we would risk being incorrect, we must not attempt
it the translation". And yet, given the simple heuristic already
implemented, it would is already taking a MUCH greater risk by
assuming that just because the other files don't have both LF and
CRLF in the same file somewhere, they are obviously not binary!
So go ahead if you have some intelligent input, but note that I will
not bother to respond if you try to say things already covered in
that recent "Hate about Subversion" thread, or if you are just trying
to argue choice of words... I'm trying to understant what people
*mean*, not pick out-of-context points I can argue with.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: So which is subversion wrong about; changing imported files
Posted by Ryan Schmidt <su...@ryandesign.com>.
Yeah, I'm not sure what exactly your question is, but I will say this:
On Mar 2, 2007, at 13:47, Jeff Smith wrote:
> 1. Subversion will always PRESERVE the original file when importing
> (many authors)
[snip]
> I can completely support 1, however:
> The problem is that those insisting that 1 is solid have also proven
> to me that when dealing with svn:eol-style (in auto-properties),
> Subversion breaks the law. In the repository, it "normalizes" the
> file. Read "I, Robot" by Isaac Asimov, and see that these guys are
> probably calling it "normalize" instead of "modify" to save
> developers from breaking down, realizing that they have actually
> modified the file on import. Once imported, there is ABSOLUTELY no
> indication of whether that file originally ended lines with CR, LF,
> or CRLF characters. Let's face it... the file has been modified! I
> would rather subversion be consistent, but preserving this file.
AI think I agree: Subversion has modified the file. However I think
that by using the svn:eol-style property, you have asked Subversion
to modify the file. I'm not sure how the feature could otherwise
function.
In researching this earlier, I found a Wikipedia page describing the
Unicode-approved way of dealing with newlines in a file:
From http://en.wikipedia.org/wiki/Newline#Unicode :
> The Unicode standard addresses the problem by defining a large
> number of characters that conforming applications should recognize
> as line terminators:
>
> LF: Line Feed, U+000A
> CR: Carriage Return, U+000D
> CR+LF: CR followed by LF, U+000D followed by U+000A
> NEL: Next Line, U+0085
> FF: Form Feed, U+000C
> LS: Line Separator, U+2028
> PS: Paragraph Separator, U+2029
>
> This may seem overly complicated compared to a simple approach like
> converting all line terminators to a single character, for example
> LF. The simple approach breaks down, however, when trying to
> convert a text file from an encoding like EBCDIC to Unicode and
> back. When converting to Unicode, NEL would have to be replaced by
> LF, but when converting back it would be impossible to decide if a
> LF should be mapped to an EBCDIC LF or NEL. The approach taken in
> the Unicode standard allows this transformation to be information-
> preserving while still enabling applications to recognize all
> possible types of line terminators.
So, it seems the Unicode recommendation coincides with your feeling
that Subversion should preserve whatever line endings the file
contains, and not modify them. However this requires all tools you
use to also obey this, and recognize all the above Unicode characters
as line endings. Subversion can of course achieve this preserving
behavior if you simply do not set the svn:eol-style property. It
seems that any use of the svn:eol-style property the way Subversion
currently implements it (and perhaps even in any way in which it
could be implemented) is in violation of the above Unicode line
ending principles.
If the only reason for the Unicode recommendation is support of
EBCDIC systems, then one can decide for oneself how important EBCDIC
support is. To me, for example, it's not important at all.
I'm not sure if I'm arguing for any particular behavior in Subversion
or recommending any particular practice by people who use Subversion,
just noting what I found.
--
To reply to the mailing list, please use your mailer's Reply To All
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: So which is subversion wrong about; changing imported files
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 6, 2007, at 18:28, Jeff Smith wrote:
> So now I get the idea that subversion would have had a better start by
> not allowing an immediate "eol-style solution" on import. Instead, it
> should always import the initial rev as-is. Then for a convenient
> auto-props feature, it should make a _next_ revision with useful
> modifications such as normalization--or perhaps only translate eol
> (according to svn:eol-style) as files leave the repository, although
> perhaps internal normalizing is done for speed or simplicity.
>
> An example is almost demonstrated in the comment that mixed eol-styles
> are "handled" when the vendor releases (imported without auto-props)
> are merged into a tree in the trunk which already has desired files
> set with svn:eol-style. The problem is, how to I get them all
> automatically set without being able to use auto-props?
You're saying: you have imported a tree without using auto-props, and
now would like to apply properties globally to what's already in the
repository? I think that's what the svn_apply_autoprops.py script in
the Subversion source distribution is for:
http://svn.collab.net/viewvc/svn/tags/1.4.3/contrib/client-side/
svn_apply_autoprops.py?view=markup
There's also another version of this script written by Matthew Good
which is supposed to have better performance and also SVK compatibility:
http://matt-good.net/2005/12/23/new-and-improved-svn-apply-autoprops-
py-now-with-more-svk/
--
To reply to the mailing list, please use your mailer's Reply To All
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: So which is subversion wrong about; changing imported files
Posted by Jeff Smith <js...@robotronics.com>.
On Tuesday 06 March 2007 20:31, Ryan Schmidt wrote:
> You're saying: you have imported a tree without using auto-props,
> and now would like to apply properties globally to what's already
> in the repository? I think that's what the svn_apply_autoprops.py
> script in the Subversion source distribution is for
Ah thank you very much! I thought someone mentioned a script without
saying what it does nor that it was what I wanted, but I could not
find the post again.
Hopefully this will be the key to solve my trouble :-)
I'd just track the vendor releases of FreeRTOS the way they come, copy
the first one into my trunk, use svn_apply_autoprops on that copy.
Then I can supposedly merge further vendor release changes with my
trunk, and it will ignore the mass-confusion of mixed eol-styles that
are always in the ports.
Thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: So which is subversion wrong about; changing imported files
Posted by Jeff Smith <js...@robotronics.com>.
On Friday 02 March 2007 20:31, Ryan Schmidt wrote:
> AI think I agree: Subversion has modified the file. However I think
> that by using the svn:eol-style property, you have asked
> Subversion to modify the file. I'm not sure how the feature could
> otherwise function.
[ On a sidenote; that being an option was exactly my point, when
certain people disagreed strongly whether there should be an
__OPTION__ (...just making sure certain people notice that word...)
to allow svn:eol-style to also accept a file with mixed eol-styles.
I'm glad you understand, but that was not what I wanted to discus
right now...
]
So now I get the idea that subversion would have had a better start by
not allowing an immediate "eol-style solution" on import. Instead, it
should always import the initial rev as-is. Then for a convenient
auto-props feature, it should make a _next_ revision with useful
modifications such as normalization--or perhaps only translate eol
(according to svn:eol-style) as files leave the repository, although
perhaps internal normalizing is done for speed or simplicity.
An example is almost demonstrated in the comment that mixed eol-styles
are "handled" when the vendor releases (imported without auto-props)
are merged into a tree in the trunk which already has desired files
set with svn:eol-style. The problem is, how to I get them all
automatically set without being able to use auto-props?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org