Re: [Monotone-devel] OS-specific line endings

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Am 04.07.10 00:53, schrieb Stephen Leake:
>> Thomas Keller <address@hidden> writes:
>> 
>>> Am 03.07.10 18:37, schrieb Stephen Leake:
>>>> project.pin is written by Quartus, using OS-specific line endings. So
>>>> when I rebuild on the other OS, 'mtn status' reports a bogus change;
>>>> only the line endings have changed.
>>>>
>>>> project.qsf is written by me, and by Quartus (because it assumes I'm
>>>> using the GUI to edit options, even though I'm actually using Emacs).
>>>> Again, 'mtn status' reports bogus changes.
>>>>
>>>> I can invent an attr 'os_line_endings', and add a function to the
>>>> 'attr_functions' hook to change the file line ending on workspace
>>>> update. But that doesn't fix the bogus changes reported by 'mtn status'.
>>>> In fact, it makes it worse; I only get the bogus changes now when I
>>>> actually run Quartus. The same workspace contains Ada code, which I
>>>> compile far more often. With this attr, I'll get bogus changes all the
>>>> time.
>>>
>>> I'm for implementing a --no-whitespace option to diff to ignore all
>>> whitespace changes (line endings, indentation, etc.) - this should solve
>>> the main problem. I meant to work on this, but couldn't find time for it
>>> until now.
>> 
>> That would help in diff, but 'mtn status' doesn't use diff to detect
>> changes; it uses calculate_ident. So it would not solve the main problem.
>> 
>>> And then, we could of course invent and implement a custom attribute,
>>> like mtn:native_eol, and mangle the line endings in attr_init_function.
>> 
>> Yes. But that also does not address 'mtn status'.
>
> I don't know, but the more I think about it, the less I think its a good
> idea to deal with this at all. If we change core mtn internals to behave
> differently based on what kind of line style is preferred by the user,
> we could introduce a lot of unwanted behaviour / bugs. At least prefer
> to know for sure that monotone keeps my contents in-tact and unchanged
> in the repository as well as the workspace.

In general, I agree.

But I still want to address my particular problem.

So munging file endings only for files that have an attribute explicitly
set by the user (never by default) should be acceptable.

I'm more concerned about the implementation and its impact on speed.

-- 
-- Stephe