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

[Richard Levitte - VMS Whacker]

In message <address@hidden> on Wed, 1 Feb 2006 21:19:37 -0500, Ethan Blanton 
<address@hidden> said:

eblanton> Richard Levitte - VMS Whacker spake unto us the following wisdom:
eblanton> > In message <address@hidden> on Wed, 1 Feb 2006 07:24:22 -0500, 
Ethan Blanton <address@hidden> said:
eblanton> > eblanton> Richard Levitte - VMS Whacker spake unto us the following 
wisdom:
eblanton> Let me also clarify exactly what I am talking about:
eblanton> 
eblanton> 1) Database line-endings are LF
eblanton> 2) Platform line-endings are provided
eblanton> 3) On database checkout, *only* LF is converted to the
eblanton>    platform line-ending
eblanton> 4) On database checkin, *only* the platform line ending is
eblanton>    converted to LF
eblanton> 
eblanton> Given this set of rules, I claim that *text conversions* are
eblanton> as optimal as can be expected.  Monotone seems to differ
eblanton> from this case in that CR is also considered for conversion,
eblanton> _even if bare CR is not a platform line ending_.  *This* is
eblanton> what I say is broken, and needs to be fixed.

monotone differs in that it currently always considers CR, LF and CRLF
to be line endings.  They will all be converted to LF on checkin.

eblanton> > eblanton> The working space corruption is a problem with
eblanton> > eblanton> whether or not the file was marked binary, which
eblanton> > eblanton> is orthogonal.
eblanton> > 
eblanton> > Really?  If we treat binaries as "DO NOT TRANSFORM IN ANY
eblanton> > WAY", would you still say there's a corruption problem?
eblanton> > How?
eblanton> 
eblanton> There is not.  But there is currently a TEXT FILE corruption
eblanton> problem.  Binary files are just a complication thrown into
eblanton> the mix.  I agree that the binary file problem also has to
eblanton> be solved.

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.

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).

Also, from the point of view of what needs to be changed in monotone,
I see the "don't touch this file" and the "conversion of line ending"
problems as quite separate.  The only real connection between the two
is that a "don't touch this file" marking would prevent "conversion of
line ending" from occuring.  Matbe we should discuss handling of
non-transformable files in another thread?

eblanton> > eblanton> I don't understand what the pushback is here ...
eblanton> > eblanton> Yury seems to be suggesting something which is
eblanton> > eblanton> clearly correct to me, and it's being conflated
eblanton> > eblanton> with a separate problem (marking files as
eblanton> > eblanton> binary) and dismissed.

OBTW, regarding that; no, I'm not dismissing it.  In a response to
Yury, I actually accepted it, AND moved on to "how do we solve
non-transformable files"?  I should have clarified that I'm keeping
the line ending problem in mind.  I'm actually exploring it on my
laptop right now.

eblanton> I don't understand what is not reversible about the above.
eblanton> There are situations where it breaks down (e.g., CR local
eblanton> line ending, and actual CRs occur in the text document), but
eblanton> it is a far sight better than what I understand is the
eblanton> current conversion.

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.  Then again, I'm half Swedish, half French, and English is
just my third language, so it's quite possible we're hitting a natural
language issue.  You tell me.

And so we don't get side-tracked in another argument; no, I'm saying
that monotone's current behavior is reversible.  It isn't.  But for
what I consider a text file, I don't see it as an issue.

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.
Think about it.  However, if we do this, we will get migration hell.

Cheers,
Richard

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

-- 
Richard Levitte                         address@hidden
                                        http://richard.levitte.org/

"When I became a man I put away childish things, including
 the fear of childishness and the desire to be very grown up."
                                                -- C.S. Lewis