monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Re: line endings as project policy


From: Bruce Stephens
Subject: [Monotone-devel] Re: line endings as project policy
Date: Mon, 27 Nov 2006 22:22:38 +0000
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.91 (gnu/linux)

"Justin Patrin" <address@hidden> writes:

[...]

> As a heavy user of version control systems (CVS, SVN, and MTN
> mostly) I'm also against any automatic conversion of text line
> endings. While I understand that "some editors" and "some programs"
> don't like certain line endings, in the general case it's easier to
> just leave things as they are. Most programs and editors are fine
> with any type of line ending and will work correctly on them. If
> there is a problem then the user or repository manager can set a
> setting that will convert the files. The default should always be
> "leave it alone, let the user/repo admin/person checking in decide
> whether to convert".

But what if it could be done so that almost all of the time things
just work, and when they fail the worst that you have to do is set an
attribute or two?

I'm thinking of the common case, where almost all the files are text
(source files, HTML, etc.) with a few obviously binary files (with
obviously binary-indicating extensions like .jpg, .png).  In that case
(for the text files) canonicalising line endings and (on checkout)
using the platform's native conventions is surely best.

There'll be the odd occasion where some text file requires a specific
convention, but that's OK: let me override the default.

Otherwise many projects will end up with some files having LF line
endings and some with CRLF line endings.  That feels wrong: we can do
better.

There's a danger of losing information if one tries to canonicalise
line endings which are (deliberately) inconsistent within a file.  So
check first, and refuse to do that.  (Require some attribute to be
set, I guess, either indicating the line endings don't matter, or that
the file should be regarded as binary.)

[...]





reply via email to

[Prev in Thread] Current Thread [Next in Thread]