[Top][All Lists]

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

RE: DOS EOL pollution in repository

From: David L. Martin
Subject: RE: DOS EOL pollution in repository
Date: Wed, 14 Mar 2001 23:53:07 -0600

> From: David L. Martin [mailto:address@hidden 
> Commented out from the script is an alternative 
> "automatic" way to determine whether the file 
> is ASCII using the Unix file command.

> From: Jerry Nairn
>A better way of doing this is with "cvs -n log -h". One line of the output 
>will be 
>"keyword substitution: kv" 
>for all of the files which cvs is treating as text. 
>If you're doing some funny things, you might want to allow
>this check on some other keyword substitution modes, like kvl.
>Certainly you would never run this check on anything with mode b.

Unfortunately, this would not work on a file that does not yet exist in the
repository.  It is often the case that the first revision of a file committed is
one strewn with undesired DOS EOL.  You could in this particular case
use the result of a cvs status to see that it is Locally Added and that it has a
kb sticky option.  You are, however, putting trust in the user that the he/she
has appropriately assigned the keyword expansion mode to define whether
the file is binary or not.  This is why I suggested the possibility of an
automatic binary/text determination.

Along these lines, I like the way WinCVS issues a warning if an apparently
binary file is added as a text file (and vice versa).

Use of the cvswrappers file is effective in defining which files are
defined as binary for imports and adds - as long as no keyword expansion
override is specified.  For example, cvswrappers *will* save you if you
issue a cvs add <binaryfile>, and <binaryfile> is listed in some search
criterion in cvswrappers to be -k 'b'.  But, cvswrappers *will not* save you
from adding a text file erroneously as a binary file (e.g. cvs add -kb 
But this case has far less severe implications than adding a binary file
erroneously as a text file.

The more severe problem is in the use of cvs update -kk during merges to
avoid keyword conflicts.  Any newly added binary files will be committed with
the keyword override -kk, thereby losing their binariness, irrespective of
the cvswrappers content.  And that is a topic for another thread not to be
rehashed here.... ;)


reply via email to

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