Last day to vote/reject on proposed EOL names

[Mark Hammond]

Hi Alex,

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?

> 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?

> crlf (crlf in wt, lf in repo)

I remain skeptical of this one.  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