Re: cvsignore

["Greg J. Badros" <gjb at cs dot washington dot edu>]

Jim Blandy <jimb@red-bean.com> writes:

> > I'm confused about the CVSROOT/cvsignore file.  I was hoping that I'd be 
> > able to put patterns such as:
> > 
> > guile-core/guile-readline/Makefile
> > 
> > in that file and have it ignore those files.  A quick test leads me to
> > believe that only the basename is allowed, and that the path-prefix
> > cannot be used.  I.e., if I want to ignore Makefile, I have to ignore
> > *all* Makefile-s in all modules of the repo.
> > 
> > If this is the case, then I'm not sure that I buy into the idea of using 
> > a CVSROOT/cvsignore file any more (instead of per-directory, checked-in
> > .cvsignore files).  Anybody have experience making cvsignore do what I
> > want?
> > 
> > Thoughts and comments are appreciated.
> 
> If you want to ignore a specific file, then you should always use a
> local .cvsignore file.
> 
> CVSROOT/cvsignore is only useful for establishing repository-wide
> policy.  For example, suppose we wrote a compiler that generated
> .scmobj files.  Then we might want to put `*.scmobj' in
> CVSROOT/cvsignore.

Right, but the issue is whether the .cvsignore files should be checked
in.  There are non-patterns that are files that should *not* be checked
in by developers that would ideally be a part of the meta-information of 
the CVS modules.  E.g., Makefile, Makefile.in;  we don't want a rule
that says "ignore all Makefile"s, but would like to name specific ones
so that not every developer needs to have them in his/her .cvsignore
file.  I'd written before that, ideally there would be both
module.cvsignore and a personal.cvsignore, where the former was checked
in, and the latter was developer specific, and someone else remarked
about the per-repository cvsignore file that we all thought could do the 
right thing.  But I now believe it can't and we need a new feature in
CVS to get what we want.

Greg