Quoting Les Mikesell <lesmikesell@gmail.com>:
> Duncan Murdoch wrote:
>
. . . .
> The thread keeps going because even though the obviously most useful
> behavior has been described several times, you and others keep objecting
> without any particular reasons. Or they confuse text and binary files
> and somehow think that adding more options for text will break binaries.
>
> > The complaint I was replying to was this one:
> >
> >> What would be "nice" would be for it to be more forgiving about input
> >> styles and to have options to specify that you'd prefer your output in
> >> a different style than native for the client where you happen to
> >> execute the command.
> >
> > Being "more forgiving" about input styles means it would have to treat
> > non-text files as text, according to your local definition of what to
> > do.
>
> Not non-text - text that had been mis-handled by some other operation.
> Or text that you are planning to move to another platform by a means
> that doesn't understand the different between text and binaries.
>
> > If your local definition is to "convert to text file, then treat
> > like other text files", why not do the conversion yourself?
>
> Because then svn will misinterpret the conversion of representation for
> a content change and lose the ability to correctly show content change.
If I'm following the quotations here, I think Les's point is that he is not
concerned with representation changes. He doesn't care about, and doesn't want
to see, tweaks to line endings considered as "content changes".
I think that if you change any byte in the file, you've changed the file and
Subversion should not be in the business of changing any files. I agree with
Duncan that simple reversible changes for convenience might be the exception.
Any change, even to representation, is important. Line endings, after all, are
part of the contents of the file even if they don't add any semantic meaning to
the text you typed in. Just because I didn't change any words in the file
doesn't mean I didn't change the file.
I also think that a file with "mixed-EOL" proves Duncan's point. It might be
caused by a broken tool, but it also might be really important to the use of
the file. So Subversion should not be trying to sort it out or fix it.
I am sympathetic to the argument that I think Les is making. It's terribly
annoying to dig through dozens or hundreds of changes simply for linefeeds,
tabs or spaces. That can get really ugly and I hate it too.
But I believe that sorting through those differences (or using a diff tool that
hides them for you) is better than trying to have Subversion manage it.
If Subversion did, then I could have to explain why a file that looks the same
because of "forgiveness" on line endings has different checksum or size from
the identical file outside of Subversion. When all this matches up, I have
external evidence that Subversion can be trusted. If it doesn't, I have to
start explaining eol-style and the difference between "content" vs. "contents".
Sorry to continue the thread, but this is a really important subject for me.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 2 17:40:10 2007