monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: Looking at the code affected in bug 9752 leaves


From: Richard Levitte - VMS Whacker
Subject: Re: [Monotone-devel] Re: Looking at the code affected in bug 9752 leaves a weird taste...
Date: Wed, 18 Aug 2004 14:26:49 +0200 (CEST)

In message <address@hidden> on Wed, 18 Aug 2004 13:14:45 +0200, Jon Bright 
<address@hidden> said:

jon> Richard Levitte - VMS Whacker wrote:
jon> 
jon> > If we're discussing MIME types, we're gonna get back to line end
jon> > conversion for text/* types, so I'm guessing that when you talk about
jon> > "canonical form", we're not just gonna store the file as it is.
jon> 
jon> Canonical form should almost certainly be LF-only for text files,
jon> but it doesn't really matter whether it's LF-only or CR+LF, so
jon> long as there *is* a canonical form in the DB.

Well, one-character line endings are easier to parse and are
unambiguous, so my vote goes to LF, hands down.

jon> I'd argue MIME types aren't useful in this context.

Having thought some more about it, I agree, and so does Bruce as far
as I understand.

jon> We're only really interested in two types of file, text and
jon> binary.  For text files, we're further interested in whether the
jon> text file wants the local line-ending convention when it's
jon> checked out or some fixed one.

I'm not sure why we would need to keep track of anything but the local
line-ending.  Really.  Text is text.  Text is a vector of lines,
basically.  Line ending isn't really something that should be
considered part of the text per se.

We might want to recognised all standard line-ending sequences (i.e.
CRLF, CR and LF) when reading a file, but that should be about all.

jon> Wouldn't a --type=[text|text-alwayslf|text-alwayscrlf|binary]
jon> parameter be easier for all concerned?

--type=[text|binary], IMHO.

jon> (Does text/plain even imply a line-ending convention?)

No, not as far as I know.  Line-ending convention belongs in protocol
definitions, not in the MIME-type definitions.  It wouldn't work in
record-oriented file systems, where no line-ending character is stored
at all.

jon> When re-examining the file later (after checkout), I don't think
jon> we really care what line-ending it's got at that point - a line
jon> ending's a line ending's a line ending, as far as monotone's
jon> concerned, and they're all going to be canonicalised?

You and I are basically saying the same thing, it seems to me.

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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]