Last day to vote/reject on proposed EOL names

[Mark Hammond]

On 2/04/2009 7:07 PM, Alexander Belchenko wrote:
> And such people will complain about rejected commits and blame VCS who
> reject their commits, and so on, so on, so on.

But I'm advocating a situation not unlike what svn provides.  I've seen 
no evidence to suggest this is a failure due to users not understanding 
the rejection message svn provides in similar situations.

As I've mentioned, there doesn't appear to be a *practical* scenario I 
accept this as being a problem - they all revolve around a tool-chain 
involving one brain-dead tool only supporting one EOL style and another 
only supporting the other - plus people making checkins where (a) they 
have clearly not tested the change and (b) are too naive to understand 
the implication of what they are doing.  IMO this can be treated like 
any other change which breaks things due to it being untested - just 
revert it and move on.

> Given this into account, I'd prefer to have optional support for non-native
> variants. You don't need them? Don't use it. I don't see *the* problem.
>
> What's the problem?

The problem is that bzr may guess it should change my content underneath 
me.  Semi-smart editors (ie, too dumb to fix copy-paste EOLs, but smart 
enough to notice changes underneath them) which are running when the 
tree is updated may report the file was changed causing confusion for 
the user.  The problems resulting in bzr *not* doing a transform seem 
artificial IMO.  So I see practical problems in bzr changing stuff 
underneath me, and no practical ones in bzr *not* doing that.

Cheers,

Mark