At 09:39 2007-02-02, Erik Hemdal wrote:
>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.
THAT'S PURE CRAP!!!!!
there are many cases in which it simply is NOT a true statement
> 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.
then save your danmed files as binary, they are NOT "text"
>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
Victor A. Wagner Jr. http://rudbek.com
The five most dangerous words in the English language:
"There oughta be a law"
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Feb 5 04:28:02 2007