RE: [Monotone-devel] Re: line endings with 0.31

[Kelly F. Hickel]

[...]
> > Now, please, before you start reacting, I *know* that the whole file
> > isn't stored, only the delta.  Unfortunately, I know diddly over
> > squat about xdelta, so a question is if storing different EOL
> > formats at different times creates more trouble than it's worth.
> 
> Not sure.  It would make the deltas bigger (if the delta represented a
> single-character change you might need a separate copy for every line
> (perhaps plus a record for the EOL) rather than two big copies plus
> the changed characters).  I'm not sure whether that would be
> significant over the lifetime of a repository.  It might well depend
> on usage patterns.
> 
> I must admit it feels like the wrong way to do it.  Better (I'd have
> thought) to store some canonical form in the repository and let the
> clients do conversion.  What's currently missing is a way to specify
> what the canonical form ought to be like: whether the file's text or
> binary, whether it has special line-ending requirements (like some VS
> files seem to have).  Subversion splits this: svn:mime-type specifies
> whether a file's binary or not, and svn:eol-style lets you change the
> line ending.
> <http://svnbook.red-
>
bean.com/nightly/en/svn.advanced.props.html#svn.advanced.props.special.m
im
> e-type>,
> <http://svnbook.red-
>
bean.com/nightly/en/svn.advanced.props.html#svn.advanced.props.special.e
ol
> -style>.
> 
[...]
[Kelly F. Hickel] I have to say that having the mime-type of a file in
an attr store in the repo seems like it can only be a good thing to me.
You have to figure out how/when/where the mime type gets figured out,
and allow it to be changed after the initialz commit for the cases where
the "guess" was wrong.  This argues for storing the file the repo in as
unchanged a way as possible so that no damage is done if the mime type
is changed.

But, once you have the mime type, many new things seem to be possible.
And it would seem to help with the character code conversion issue as
well.  Perhaps symmetric (or at least "symmetric enough" ;> )
conversions could be defined, stored in the repo, so that clients can do
conversion if needed.

So, to sum up, my "votes" would be:
1) conversion is done on the client side
2) files are stored in the repo in an as unchanged way as possible
3) meta information is stored as an attr, allowing the client to make
conversion decisions
4) whatever decision the client makes to do conversion must be able to
be overridden by the user.  This is required, for instance, when doing a
checkout on windows into a network mounted workspace that would have
different conversion requirements.

-Kelly