Re: Spaces added

[David L. Martin]

> address@hidden (Larry Jones) writes:
> 
> > address@hidden writes:
> > > 
> > > I found out recently that when we check out some code that was only 
> > > recently placed in the repository that it has extra spaces between 
> > > the lines that weren't there before. Could it be that something was 
> > > done wrong when the code was originally placed in the repository and 
> > > is there a way to strip these extra spaces out while preserving the 
> > > code? Also when looking at the code with different tools, like 
> > > Tonrado 2, there won't be extra spaces, but there is an extra 
> > > character that looks like a bold pipe at the end of each line.
> > 
> > My guess is that someone checked in DOS/MS-Windows files on a Unix
> > machine and now you've <CR> characters at the ends of the lines that
> > some tools are displaying as newlines and others are displaying as
> > funny characters.  If that's the case, you need to check the files out,
> > fix them, and commit the changes.  You may have some kind of DOS-to-
> > Unix program on your Unix system that you can use to fix them, or you
> > can use tr.
> 
From: "Laine Stump" <address@hidden>
> I've also had good luck just running a dos2unix utility over the ,v
> file in the repository - make a backup first, though, as I might have
> just been lucky!
> 

Yeow!
I guess that would work on the ,v files, if they're known to be ASCII files.
I would typically run dos2unix on the affected file and commit to
provide unix linefeed termination on the tip revision.

I finally got so tired of doing this whenever someone used an editor that
added ^M at the end of line that I added a script to commitinfo to check
for end-of-line ^M and reject the commit if present for certain file types.
This is particularly pernicious in GNU makefiles or sh/ksh scripts.  Even
for source files that are unaffected in compilation or execution by
the EOL type (e.g. .java or .c files), different EOL types within a single
file can cause a ridiculous number of merge conflicts.

I think it is the responsibility of the CVS administrator to proclaim a
standard, canonical end-of-line format for ASCII files (either Unix
LF, Windows LF-CR, or even Mac LF), and enforce it to keep the
repository consistent.  Many editors now provide an option on what
kind of line feed to use  files.  Others do not, and use the
client-specific default

Define a standard ASCII file EOL for your project (typically whatever
is used on your development platform), and try to enforce it...

Regards,
David Martin