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

[Bruce Stephens]

Richard Levitte - VMS Whacker <address@hidden> writes:

[...]

> What does "canonical form" mean to you?  My though was that monotone
> would store the actual bytes of the file as read from the file
> system.  This will work for any byte- and stream-oriented file
> system.

For text files, that would include conversion to and from some
arbitrarily chosen line-ending convention, yes.  If we just stored the
bytes of the file, then presumably that would mean a single product
created by both Windows and Unix developers would end up with files
with a mixture of line-endings (and perhaps the files would end up
changing in a commit even if no actual changes had been made, because
the bytewise copy on my computer is different to the one committed in
the latest revision).  

That seems crazy: in theory it's arguably the best thing to do,
because then you can be sure of being able to reproduce exactly what
was committed.  But in reality it rarely matters that much---so the
system can be potentially slightly lossy most of the time, so long as
precision is available when you need it.

> If we should ever think about record-oriented file systems,
> like the one used on VMS, that's another level of portability (and
> worms).

Indeed.  I think it's best to ignore such systems for the moment.

[...]

> The question is, what should monotone do when a file is added?  It
> could use "standard" things like the command 'file' and the MIME
> type mapping file 'mailcap', when available, but other than that,
> how should it behave?  Maybe there should be an option '--type' that
> can take a MIME type?

It should do what it presumably does now at some point: if the file
looks like binary, then regard it as such, otherwise, regard it as an
ordinary text file and convert it.  It could try and be clever, so if
I add a text file on Unix that has CRLF line endings, then it could
guess that the file should always have CRLF line endings.  That's
probably worth doing.  Recognising text files on Windows that have LF
line endings would also be possible, but less useful, I suspect.

> If we're discussing MIME types, we're gonna get back to line end
> conversion for text/* types, so I'm guessing that when you talk
> about "canonical form", we're not just gonna store the file as it
> is.

Probably MIME types are the trendy things to use, but then you'd need
some way to work out what they actually mean in terms of conversion.
I'd guess something simpler would do: text, binary, text with LF
endings, text with CRLF endings.  (Maybe text with CR endings, for any
Mac purposes.)  And the default ought to be text (which converts
between platform conventions and the canonical convention).