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

[hendrik]

On Mon, Nov 27, 2006 at 10:22:25AM -0800, Justin Patrin wrote:
> On 11/27/06, address@hidden <address@hidden> wrote:
> >On Mon, Nov 27, 2006 at 11:52:53AM +0000, Bruce Stephens wrote:
> >> Richard Levitte - VMS Whacker <address@hidden> writes:
> >>
> >> [...]
> >>
> >> > That leads me back to thinking that we still need to mark files that
> >> > are getting changed, and that something automatic should happen to
> >> > them, so a file will look the same checked out as before it got
> >> > checked in.
> >>
> >> I'm sure we discussed all of this the last time around (and probably
> >> the time before that; possibly I'm thinking of discussions in OpenCM
> >> or GNU Arch).
> >>
> >> Storing things as binary seems easy, but that's likely to cause
> >> irritation for projects that use Windows and Unix.
> >>
> >> More aggressively converting files that look texty also seems not too
> >> hard, but it may break files that have inconsistent line-endings, and
> >> files that are text but require a specific line ending convention.
> >>
> >> On the whole I think the second is a better option.  Basically do what
> >> subversion seems to do: guess when files are text, and mark them as
> >> such; have an option that lets people specify the line-ending
> >> conventions of a file, but by default assume the native convention.
> >
> >I remain against doing any conversion based on a guess.
> 
> As a heavy user of version control systems (CVS, SVN, and MTN mostly)

So you might be qualified to report on their relative merits in actual 
use?  I've found charts on the web comparing features, but these give me 
no insight into what happens in practice -- what the real day-to-day 
irritations are.  Any experience with bzr?

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

Some OS's make it hard for rank beginners (though possibly experienced 
on other systems) to find out how to do the necessary conversions.  But 
that is not a version control problem.

> 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".

Of course, being to be able to declare the file format and get a 
syntax check (such as correct line-endings) would be quite helpful in 
it was done cleanly and allowed revisions to explicitly change the file 
format as well as the contents.  This does open the door to a very long 
corridor of potential syntax checks, but I suggest we leave C's syntax 
check to the C compiler.  (Actually, this corridor has a number of 
interesting rooms on it, such as custom merge algorithms for specific 
file types -- I can imagine, for example, that edited JPEG images might 
usefully be merged by quite different algorithms from C source code. :-)

But conversions should be requested explicitly.  I wouldn't even 
mind if a request for conversion-to-local on checkout were to be treated 
as a request for conversion-back-to-archive on checkin if the 
conversions were one-to-one and reversible.

-- hendrik