info-cvs
[Top][All Lists]
Advanced

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

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


From: Laine Stump
Subject: Re: Spaces added ... and line endings in general
Date: 24 Jan 2001 18:51:15 -0500
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

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

Eric Siegerman <address@hidden> writes:

> On Tue, Jan 23, 2001 at 06:40:19PM -0500, Laine Stump wrote:
> > [...] the only tool I
> > use that doesn't accept/deal with multiple line-end conventions is _CVS
> > itself_.
> 
> Your other tools deal with two line-end conventions, maybe three
> (ie. Mac), if you're really lucky.  It doesn't deal with *all*
> relevent conventions.

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

> 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. For example, I checkout a .c file
from CVS on a Unix system, then use a DOS/Windows C compiler to
compile it. All the MSVC commandline tools, as well as Emacs (on both
Unix and Windows), PFE (Programmer's File Editor), and tons of other
tools, will happily work with files having either CRLF or LF
line-endings and *automatically* dtrt (No, I am *not* suggesting that
CVS go as far as attempting to detect line-end convvention by
examining the file at run time.)

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

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

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

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

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

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.




reply via email to

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