Re: Spaces added ... and line endings in general

[David H. Thornley]

Laine Stump wrote:
> 
> (I should have known better than to get into this, but now that I'm
> already here... :-P)
> 
Me too.

> 
> Notice that I didn't say "all". I'm well aware there are a few very
> rare cases of systems that don't use one of the "standard
> three". However, those systems are not widely used, and they're on the
> way out.  What I'm talking about is something that would benefit the
> quite large group of developers who are constantly switching back and
> forth between Unix, Windows, and Mac, and who often forget which
> machine they're on at the moment, as well as which machine they were
> on when they checked something out. (It also wouldn't *hurt* that
> other small group of people using things like VMS, etc).
> 
I'd say that this group is large enough to justify some special
cases in CVS.  Others may differ.

> > CVS does, by definition (where the definition of "relevent" is
> > "CVS has been ported to it").  Automatically (see above).  As
> > long as you don't try to fool it.
> 
> Your definition of "deal with multiple line-end conventions" is
> different from mine. Mine includes using a file that was created on
> one platform with tools on another.

Which CVS does, in a sense.  Create it on Windows, check in into
the Linux box, check it out using MacCVS, and everything should
be cool.  The only problem is if you move or access files between
systems by other means.  In other words, CVS is giving you the
desired behavior, but isn't quite playing well with others.

> If I shove a bunch of LF-terminated lines at the Windows version of
> MSVC, it processes them properly; if I edit a file of CRLF-terminated
> lines with the Unix version of Emacs, it recognizes that, and all
> newly inserted lines are also CRLF-terminated. On the other hand, If I
> give LF-terminated lines to the Windows version of CVS, it croaks;
> likewise for CRLF-terminated lines and the Unix version. Emacs and
> MSVC pass, CVS doesn't. (of course, by this definition, gmake also
> fails).
> 
There are existing solutions to this, requiring an extra step.

> > How should a *single* CVS executable "accept/deal with" all of
> > the following, which it *must* do if it's to defend itself
> > against the kinds of abuse you want to throw at it?
> >   - Unix format: <LF>
> >   - DOS format:  <CR><LF>
> >   - Mac format:  <CR>
> 
> These are *simple* to deal with.
> 
Right.  Accept any of them, intermixed in a file.  Convert them
for internal processing into the system's preferred format.

Provided, of course, this isn't the only behavior, as otherwise
anybody who puts CRs into a file, intending them as something
other than line breaks, loses.

> >   - Files in which some lines use one of the above conventions,
> >     and some use another (because you edited a DOS-format file in
> >     vi on a Unix box, and didn't religiously type the ^v^m's)
> 
> These files are broken anyway.
> 
And can be fixed, if you are willing to make the assumption that
all of these conventions may be intermixed, and there is no
intentional difference between them.

> >   - Unix-format files that contain <CR>s as actual formatting
> >     characters -- perhaps even at the ends of lines, for doing
> >     overstriking, so looking specifically for <CR><LF> is unsafe
> >   - Record-oriented formats which use length words and have no
> >     terminator at all.  This is old mainframe stuff -- dying, but
> >     alas not dead yet.  (For an example, see below.)
> 
> These are more diffcult, of course. That is why the *default* behavior
> should remain as it is now - so that nobody not expecting it gets
> surprised.
> 
As long as you are proposing this as an option that will be useful
to a large number of people, I'll go along with it.
> >
> > > > But it would need to be set in variety of ways:
> > > >
> > > >     setting on file,
> > > >     overridden by .rc file,
> > > >     overridden by environment,
> > > >     overridden by cmd options
> > >
> > > YES!!!! This is exactly what I'd like to see! (naysayers be damned! ;-)
> >
> > Perhaps I'm being obtuse, but how does this help with the
> > following use case:
> >
> > > The only problem is when you do the checkout on platform X,
> > > then work with that work directory on platform Y.
> 
> Because when you checkout the directory, an indicator would be (for
> example) stored in the CVS/Entries file telling which line ending
> format was in use when the file was originally checked out. CVS would
> then be able to continue dealing with it in the same way, no matter
> which platform's CVS was subsequently used (ignoring the *extremely
> rare* case of platforms with null-terminated lines, record-based file
> systems, etc)
> 
Right.  There are people who would have problems if this were
the default (or, worse, only) behavior of CVS.  As long as they
don't have to use the proposed behavior, they should be OK.

However, why do we need to record the original line-ending format?
If we're working multiplatform with text files, why does it matter?
If I write half the files in a program with Emacs on my linux box,
and the other half with Alpha on my Mac, why do they need to be
segregated?

I'd think that the choices for a file would include either that
it is to preserve all standard line endings, or that it is to
interpret all three of the most common ones as line endings.
Leave it at that.  I don't even know if it is necessary to keep
this on a per-file basis.

> I know there are a lot of people very rabidly against doing anything
> like this to CVS. However, the fact that it comes up so often
> indicates that it should be seriously considered. I know it's not
> something that should just be slapped in in a weekend, but it also
> shouldn't be completely condemned just because a 100% wonderful
> solution isn't immediately obvious.
> 
The significant thing is whether this would benefit a large enough
group of people to make it worth doing as some sort of option.
I think it would, but I'm not volunteering to do the coding on
it.

-- 
David H. Thornley                          Software Engineer
at CES International, Inc.:  address@hidden or (763)-694-2556
at home: (612)-623-0552 or address@hidden or
http://www.visi.com/~thornley/david/