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

[Ethan Blanton]

Richard Levitte - VMS Whacker spake unto us the following wisdom:
> In message <address@hidden> on Wed, 1 Feb 2006 07:24:22 -0500, Ethan Blanton 
> <address@hidden> said:
> eblanton> Richard Levitte - VMS Whacker spake unto us the following wisdom:
> eblanton> > mlh> On Tue, Jan 31, 2006 at 07:50:51AM -0500, Yury Polyanskiy 
> wrote:
> eblanton> > mlh> > Again: solution is trivial. "Transform what I ask
> eblanton> > mlh> > you to (LF->CRLF and back) and don't mess with
> eblanton> > mlh> > anything special (like CR->CRLF etc)."
> eblanton> > mlh> 
> eblanton> > mlh> The other nice thing about this is that it's
> eblanton> > mlh> perfectly reversible, even for 'binary' files.
> eblanton> > 
> eblanton> > Provided CRLF would be the internal normal line end form.
> eblanton> > It is currently not, so the real transformation on commit
> eblanton> > would be CRLF->LF.  Then, when checking out, the reverse
> eblanton> > transformation would occur, LF->CRLF.  Here's where the
> eblanton> > fun start, what do you think happens if said binary had an
> eblanton> > embedded LF somewhere to begin with?
> eblanton> 
> eblanton> This should still be reversible.  You are correct that the
> eblanton> checked-out binary will be corrupted, but it will not show
> eblanton> up as changed, and nor would it be corrupted on checkin.
> 
> Eh?  I did not follow that.  Why would it not show up as changed?
> Compared to what?  And in what way does a binary not get corrupted on
> checkin when a LF->CRLF transformation is made?

I was talking about if the change to CRLF was *not* made.  I did not
address you "Provided ..." sentence, as it does not have to be
provided for this transformation to work; perhaps I should have
clarified that.

Let me also clarify exactly what I am talking about:

1) Database line-endings are LF
2) Platform line-endings are provided
3) On database checkout, *only* LF is converted to the platform
   line-ending
4) On database checkin, *only* the platform line ending is converted
   to LF

Given this set of rules, I claim that *text conversions* are as
optimal as can be expected.  Monotone seems to differ from this case
in that CR is also considered for conversion, _even if bare CR is not
a platform line ending_.  *This* is what I say is broken, and needs to
be fixed.

> eblanton> The working space corruption is a problem with whether or
> eblanton> not the file was marked binary, which is orthogonal.
> 
> Really?  If we treat binaries as "DO NOT TRANSFORM IN ANY WAY", would
> you still say there's a corruption problem?  How?

There is not.  But there is currently a TEXT FILE corruption problem.
Binary files are just a complication thrown into the mix.  I agree
that the binary file problem also has to be solved.

> eblanton> I don't understand what the pushback is here ... Yury seems
> eblanton> to be suggesting something which is clearly correct to me,
> eblanton> and it's being conflated with a separate problem (marking
> eblanton> files as binary) and dismissed.
> 
> The suggestion I see is that the transformation he suggests is
> reversible.  I do not see that, so either the proposal is incomplete
> (for me) and needs expansion, or we understand "reversible"
> differently, or the suggestion has flaws (which is what it looks to me
> so far).  So, if Yury could expand, perhaps by saying (and possibly
> repeating, my appologies) what transformation should be done on
> checkin, on checkout, and how binary files are safe in that kind of
> transformation, I will most certainly be able to follow.

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

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
                -- Cesare Beccaria, "On Crimes and Punishments", 1764

pgpI6Ti7SaGvZ.pgp
Description: PGP signature