[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

So which is subversion wrong about; changing imported files

From: Jeff Smith <jsmith_at_robotronics.com>
Date: 2007-03-02 20:47:48 CET

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
Received on Fri Mar 2 20:48:34 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.