On 2/2/2007 11:15 AM, Les Mikesell wrote:
> Duncan Murdoch wrote:
>>>
>>> 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,
>>
>> Okay, suppose we're on Windows, where the native format says \r\n is an
>> eol. Treating \r, \n, \r\n to be "equivalent on the way in" means they
>> all get transformed to \n in the repository, the way \r\n is currently
>> handled? Then as soon as I checked them out again, they'd all be
>> converted to \r\n. That was my first option: convert everything to
>> text. But here you've got a version control system modifying your
>> files. I don't think that's something it should do. Changing files is
>> the responsibility of the user. svn should not change files, except in
>> perfectly reversible ways (the way it currently handles true text files).
>
> I think we have a philosophical difference about the nature of text.
> Text existed long before computers with their various ways of
> representing it, and representing it in different ways does not change
> the content of the text.
I agree with you about that.
If you want to store it in ascii or ebcdic it
> is the same content. If you want to put it on punch cards that don't
> have a representation for line endings, it's still the same text. And
> it certainly doesn't change just because different currently popular
> platforms represent the line endings in a slightly different way.
I still agree with you.
The
> important thing for a revision control system handling text is that it
> can show the differences in content, not the unrelated storage format
> that may have held it at various times.
Right.
Suppose you wanted to present
> the text of a proposed amendment to a law for a vote in some political
> body. Would you show just the changed wording in its context, or would
> you have to present the entire volume in the before/after states because
> you had to copy to different media and now can't track the portion that
> may be changed?
>
> Subversion has the option of treating files as a meaningless stream of
> bytes, which is fine for other purposes. For text, it needs to track
> the meaning instead.
Right. In fact, I agree with everything you've written in this message.
But I don't think it's relevant.
We're talking about a revision control system. It needs to handle text,
binaries, everything. If the user says something is text, but then
submits something that is clearly not text according to the local
conventions for how text should be stored, then here's where we differ.
You think that the version control system should believe the user that
the file really is text, and make irreversible changes to the file so
that it can be handled as text. I think that if the user wants to make
irreversible changes to his file, then he should use an editor, or a
Perl script, or something other than a version control system. The user
shouldn't be allowed to tell svn to treat a file as text unless it
really is. Preventing accidental irreversible changes to a file should
be rule 1 for svn: and handling a non-text file as text just because a
user says to do so (possibly by accidentally naming it with a file
extension that at some other time they said was text) violates that rule.
Duncan Murdoch
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 2 19:23:37 2007