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.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 2 15:08:42 2007