Re: Updating the default cvsignore list

[Eric Siegerman]

On Wed, Feb 28, 2001 at 04:51:39PM -0500, Derek R. Price wrote:
>         *.gz                 Gzip
>         *.bz2                Bzip2

These concern me:
  - It's a commonplace that generated files and temporary junk
    shouldn't be revision-controlled, but everything else should
    be.
    
  - To generalize the above: files should be revision-controlled
    (or not) based on their role, not on their form.  (The fight
    over binary files only settled down when people stopped
    conflating "binary" with "generated", ie. stopped confusing
    the file's form (non-text) with what had once been -- but was
    no longer -- the exclusive function of non-text files (object
    code).

  - CVS should be conservative in what it *automatically* omits
    from revision control.  If it accidentally checks in a
    secondary (ie. generated) file, no harm done; the user can
    just "cvs rm" the file and get on with life.  If CVS
    accidentally fails to revision-control a primary file,
    perhaps-crucial history may be lost before the user discovers
    and rectifies the problem.

  - Thus, a pattern should only be added to the ignore list based
    on the role, not the form, of files it matches, and with
    great caution at that.

  - To ignore compressed files per se violates this; compression
    is orthogonal to whatever role a file (or at least, its
    uncompressed form) plays.  By ignoring them, CVS in effect
    tries to second-guess the user (which has already been deemed
    a Bad Thing, eg. the decision not to try to guess for -kb
    purposes whether a file is text or binary).

Leaving aside the ten I don't understand, all but one of the
current ignore-list entries is either:
  - and administrative overhead file of some sort (. and .. --
    admittedly a UNIX-centric opinion -- also CVS and CVS.adm)
  - a generated file, of a sort that should rarely be CVSified
    (*.o, .#*, etc.)
  - a common convention for user-created backup files, ie. junk
    (*.bak, *.old)
  - a convention for revision-control repositories (RCS, SCCS) --
    these were once gold, but are junk from CVS's point of view;
    to preserve their value, you have to do more than just import
    them, eg. rcs-to-cvs.  On these grounds, *,v should probably
    be added to the list.
  - some patterns fall into more than one of these categories;
    *.orig and *.rej are generated junk

Ie. they all satisfy my criterion of ignoring based on role.

The one exception, of course, is *.Z.  It's probably there for
historical reasons; if I recall, in the ancient past CVS didn't
handle binary files correctly (there was no -kb), so it was
positively dangerous to track them regardless of their role).
But now that binary files are supported, I think *.Z should be
*removed* from the list; to add other compression formats is
going the wrong direction!


>         *.flags              Linux source

These files may be generated in a limited context, but it's far
from a common convention.  Conservativeness argues against
ignoring them by default.

>         ID                   GNU id-utils database file

Likewise.  I have this in my ~/.cvsignore, but I doubt it should
be in the default list, since it's only a generated file on those
systems that happen to have id-utils installed, and even then,
only in the sandboxes of those users who happen to use id-utils.

Similarly, as a VIM user, I also have .*.swp and .sw? in my
~/.cvsignore, but I would NOT advocate putting those in the
default list; the domain in which they're dependably ignorable is
too restricted.

>         *.lib                DOS/Windows library
>         *.dll                DOS/Windows dynamic load library
>         *.sl                 HP-UX sharable library

These are system-dependent (*.sl more than others :-).  So are .
and .. from the current list, as I mentioned; also *.so, and
probably others.  Perhaps some entries on the ignore list should
be made explicitly system-dependent, so as not to ignore
everywhere patterns that only match generated files on some
machines.

>         *.dvi                TeX output
>         *.info*              GNU info file

Someone objected to *.info* on the grounds that they're often
included in distributions.  Same's true of *.dvi, so whichever
way the *.info* decision goes, *.dvi should probably follow.


To summarize:
  - it's ok to ignore generated files and junk; everything else
    should be tracked by default
  - it's NOT safe to try to intuit a file's role from its form
    (compressed, encrypted, etc.)
  - ignore *,v
  - don't ignore *.gz, *.bz2, *.flags, ID
  - ignore *.lib, *.dll, *.sl, but only on the appropriate
    systems; also consider which of the current entries should
    be made system-dependent
  - *.dvi should go the same way as *.info*, whichever way that
    is

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)