Last day to vote/reject on proposed EOL names

[Alexander Belchenko]

Mark Hammond пишет:
> On 31/03/2009 4:29 PM, Alexander Belchenko wrote:
>> (Ian has asked me to repost this mail to the list)
>>
>> Hi Ian,
>>
>> I'd like to help you as much as I can with eol landing.
>>
>> All recent discussion about user expectation is all the same I've got 
>> year ago.
>> It seems most people looking for ideal solution for this messy problem.
>> I see this as never ending story, and I really hate this situation.
>>
>> My thoughts so far:
>>
>> 1) It seems like eol is more important for new users who decide switch 
>> or not to bzr from other
>> system (often from svn). They are first class users of this feature.
>>
>> 2) Ian's design supports existing repos with mixed eols -- it's good 
>> for existing users
>>
>> 3) but exisiting users already live without eols and somehow 
>> accommodate their development process.
>> may be they have switched from crlf to lf one day in the past and lost 
>> annotations (like me)
>> or don't care about annotations, or recreate their projects with 
>> lf-only -- it does not matter much.
> 
> I'm +1 on all of those sentiments.
> 
>> a) Expect that files stored in the repo have lf-only. Based on this 
>> bzr needs following filters/labels:
> 
> I'm not keeping up like I should, but I'm not sure what the plan is for 
> binary files.  However, that lack of understanding isn't specific to 
> your email so I'll continue regardless...
> 
>> exact
> 
> This is effectively "binary", right?  In other words, couldn't we remove 
> this category by treating these files in the same way .jpg or 
> ..some_unknown_binary_format is handled?

Yes, in my understanding today bzr has no special handling of binary files,
so yes "exact" should be used for binary files.

I'm not sure about your other proposal.

>> native (native in wt, lf in repo)
> 
> Ignoring migration concerns and binary files, IIUC, this is the only one 
> which people actually want in practice?

IIUC, native is what 80% people want. May be even 95%.

>> crlf (crlf in wt, lf in repo)
> 
> I remain skeptical of this one.

Mark, we have discussed this topic last year and I remember your opinion
on variants other than "native".
It's good to see this year your opinion is still the same :-)

One can say: "if user wants to see file with the specific eol he/she should use exact. that's all"
This position will satisfy 80% users. May be even 90%.

But... that's not all for me. I have bad experience with editors that screwed up
eols, and as John said I'm too much worrying about annotations to lose them.

Changes in eols are too hard to track -- because they are invisible!
You have to use hex viewer/editor to see actual eols.

You can say it does not matter for bzr, and this is the users job to keep and watch
their eols clean and consistent. This point has the right for the life.

But! If bzr knows how to help the user and automatically track and reconcile
eols even if user used bad/wrong/dumb editor, then WHY bzr cannot help to user?
What if the developer in a hurry edit the file on customer computer where no good editor
has installed? And then commit it and don't realize eols have changed?

Situation when lf/crlf settings are needed is really small. I agree. But bzr can handle
this situation and do the right thing. Why bzr should not do this? Only because
help on eol settings will be more verbose? I understand, people tend to not read documentation..

But how can we measure good effect from support of this options and bad effect of
complication they provides, mostly this complication related to docs/help?
I really don't know. For me lf/crlf settings are good. But I'm mulling them for too
long time. May be I'm too biased and paranoid.

>  In practice, this seems to be handling 
> the case of "old visual studio tools insists on \r\n or they barf" - but 
> no one on a platform other than Windows actually cares about these 
> files.  IOW, for Windows users this is identical to 'native', and 
> although the working tree might be incorrect on non-windows platforms, 
> noone actually cares as the files aren't usable on that platform (or if 
> they are, it is not by the brain-dead windows tool which refuses to grok 
> them in the first place)
> 
>> lf (lf in wt, lf in repo)
> 
> In practice, this sounds like it is designed for Windows tools which 
> will barf if they see a \r\n line ending, and I can't imagine what tool 
> that might be.  What is the practical use-case for this?
> 
>> b) For poor souls (i.e. existing users, like me) there will be another 
>> additional option (only one)
>> to support "native in wt + crlf in repo". Other variants are not 
>> needed at all. People either
>> should use "exact" or relax and convert their files to lf, commit and 
>> then select appropriate option.
> 
> The blog you refer to implies this question: As older formats don't 
> support EOL at all, could your case be handled by a conversion process 
> as you upgrade to the new format?
> 
>> I'm thinking in the case when in the repo committed crlf or mixed 
>> eols, your filter at least should
>> emit warning to the user, or don't apply filter at all.
> 
> I agree 100% that 'naive' users should be prevented from doing something 
> contrary to the polices expressed by these rules (assuming that the 
> default, or easily-enabled rule, is that there are no rules :)
> 
> Cheers,
> 
> Mark
> 
>