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

[Justin Patrin]

On 11/27/06, address@hidden <address@hidden> wrote:
> 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?

Nope, the above three are really the only ones. I've been annoyed by
the auto line ending stuff in any other version control system so I
just want mtn to leave it alone by default. Note the use case that
Koen mentioned previosly (or was it Marcin....I forget). The gist was
that a patch, which is text, must be left as-is as the code being
patched will have its own line endings and mangling a patch will cause
patch to fail (the specific use case was source code with Windows
newlines needs a patch with Windows newlines).

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

What conversions do you mean? Any decent text editor should be able to
deal with any line ending and not mess with it. Of course, I use emacs
which does the right thing with any of the three. Leaves it alone.

However, I just thought of one case where some auto-munging would be
nice. Some of the people in my office use DreamWeaver to edit some
code and it always changes the newlines to whatever it's set to.... It
will read in any, but always save in what you have set, which is of
course mac newlines by default. It would have been nice if the VCS
said "newlines are different" and stopped the checkin as I then have
to go fix that person's editor, then change the newlines on the files
they changed, then re-check them in which kills the log/blame.

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

Sure. A mime-type setting should be enough for such a thing, I'd
think, and then settings about which merger to use for each mime-type.

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

Sure.

--
Justin Patrin