Re: [Monotone-devel] Re: Bug in CRLF conversions

[rghetta]

Richard Levitte - VMS Whacker wrote:
> Ah, this one hit the nail.  We still disagree on what a text file
> really is.  To me, a "text file" with embedded control characters (ANY
> embedded control character, like \r on a Unix system unless it's part
> of \r\n) are not really text files, they should be considered binary.
> Whatever conversion you do one those, you can be sure the result will
> be trash on a platform with different line endings.
> 
> Maybe we should talk about "transformable" and "non-transformable"
> files, so we don't get confused by what we consider to be text and
> binary?  I think I'll do so from here on.
+1

> Also, because of this, it seems like you and I put different focus on
> "transformable file corruption" and "non-transformable file
> corruption".  I'm much more worried about the latter (and please
> understand that from my point of view, those "text files" with
> embedded control characters are really part of the latter).
+1

> Oh, so you and I do understand "reversible" differently.  To me,
> "reversible" means there is a 1 to 1 mapping between the original file
> (the one being checked in) and the resulting file (the one being check
> out) in all possible cases.  If there's any way when a conversion back
> then forth doesn't get you back to the original, I can't see that as
> reversible.  
+1

> Btw, something in Yury's example made me think a bit, and it occured
> to me that if the database line ending would be CRLF and we only
> convert from and to the platform specific line ending, we would have
> something reversible the way I understand "reversible" (this is under
> the condition that no file ever magically appears in the database
> without having been committed to it).  And in this case, it would work
> to do this with ALL files back and forth, even non-transformables.
I don't understand what you mean. Under your definition of
non-transformable and reversible, any file with embedded CRLF can't be
properly converted "back and forth".
Trasformable files, however, can be converted correctly wathever is the
normalized line ending.

I think monotone should *not* change the file unless instructed to do
so, i.e. every file should be non-transformable by default.
Transformable files instead could be converted between "equivalent"
forms, e.g. with a different line endings, with a final line ending
sequence attached, a different encoding, and so on.
Even these transformations should be explicitly requested, imho.

Perhaps we should consider a set of attributes (explicitly or through
tables) describing how to treat a file when committing, merging,
checking out.
Some of these attributes could be overriden by the user, to allow for
different line ending or merge tool preferences.

Ciao,
Riccardo