On 2/2/07, Les Mikesell <lesmikesell@gmail.com> wrote:
>
> Duncan Murdoch wrote:
>
> > I think it's about time to quit this thread, because you're talking
> > about something quite different from svn here. svn does allow you to
> > leave files unchanged: that's the default, to treat them as binary. svn
> > does allow you to convert line endings on text files to the local
> > convention.
>
> 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 your
> > local definition is to maintain some weird combination of eol styles,
> > but do it in the native way for the platform you're working on, how is
> > svn supposed to know what that is?
>
> Svn should know what to do like it knows every other option. It should
> have a way to pass the options you want.
>
> > It can maintain the file unchanged
> > on all platforms, but I can't see any reasonable way for it to handle
> > transformations necessary to make it native when it wasn't native in the
> > first place.
>
> Given the possible combinations, it is not at all difficult. Generally
> you'd want \r, \n, \r\n, and an oddball \n\r to be equivalent on the way
> in, and a client-side option to specify one of those choices to be
> considered 'native' on the way out, even if it isn't native for the
> client where you happen to run the svn program. The inbound operation
> could be an option if anyone thinks it would break something compared to
> current text handling, but I think it should be the default. The
> latter would have to be a new client-side option.
Personally, I think it's completely scope of subversion, but here goes my 2
cents. I like to solve complex problems with simple solutions.
1) Create a pre commit hook script that invalidates windows cr-lf.
2) Tell your windows users to use a good text editor that supports linux
line breaks. I like this: http://www.editplus.com
Eric Lemes
Received on Fri Feb 2 15:27:22 2007