Last day to vote/reject on proposed EOL names
skippy.hammond at gmail.com
Thu Apr 2 10:40:24 BST 2009
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.
More information about the bazaar