[Top][All Lists]

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

Re: .cvsignore file being ignored

From: Greg A. Woods
Subject: Re: .cvsignore file being ignored
Date: Thu, 5 Jun 2003 21:43:37 -0400 (EDT)

[ On Thursday, June 5, 2003 at 15:23:16 (-0700), Paul Sander wrote: ]
> Subject: Re: .cvsignore file being ignored
> I agree with the first part, but I don't believe that the second part
> was really considered by the designer and the implementation came out
> the way it did by default.

Actually it was.  Search your list archives.

Usually every time it's been discussed since people are much quicker to
understand what Larry and I have been trying to say.  Perhaps that's
because previously more of those questioning this behaviour have had a
deeper understanding of what wildcard filename expansion really imply to
how command line interfaces work and how they must be used.

Once upon a time I posted:

        CVS' "add" command, when used on a new file, tells the local
        working directory that the new file is "source".  The CVS ignore
        list can declare that a file is not source, *BUT* CVS is allowed
        to over-ride the ignore list.  A "known" file will never be
        ignored no matter how many times or places you put it into the
        ignore list.

    I.e. "cvs add" and .cvsignore compliment each other.

In other words the ignore list is _NOT_ used to control which files CVS
acts upon.  CVS always acts upon the files you tell it to act upon.

The ignore list is used only to control which files _not_ warned about
when CVS is operating in its normal recursive mode, since otherwise CVS
would warn the user to take control of all the files it finds in the
workspace.  The purpose of the ignore list is quite explictly _NOT_ to
prevent the user from telling CVS to treat a file as source which it
would otherwise ignore but rather it is there only to prevent CVS from
being too noisy about files it isn't already tracking in the repository.

> Consider the use of "cvs import", which obeys the .cvsignore file.

That's a historical artifact as well, though perhaps one that might be
easier to change than with "cvs add".

If I'm not mistaken the ignore list feature was originally designed only
to be used during "cvs update".  Conceptually its purpose is to deal
with working directories whenever CVS is doing its own directory

I'm not sure when exactly "cvs import" first honoured the ignore list,
though with hindsight we can see that it should never have done so.
Unfortunately things only got worse when .cvsignore files were honoured
even when '-I !' is explicitly specified.  See the manual for further
discussion of this.

If you recall my proposal to enhance "cvs add" you might remember that I
suggested the new version would behave (with respect to directory names
given as command line parameters) as follows, simulating "cvs import" to
some extent, but at least fixing the documented bug in "cvs import -I !":

  - "cvs add dirname" will recurse through the specified directory
    adding all new ``un-ignored'' files if the current directory, or one
    of the parent directories, is a valid CVS working directory (as
    above).  (including if "dirname" == "." || == "")

      - Nothing will be done if no new files are found to add.

      - "cvs add dirname" will honour the '-l', '-R', and '-I' "Common
        Options" just as every other command which operates recursively.

      - "cvs add -I ! dirname" will not ignore any files, not even those
        listed in any .cvsignore files, except of course all CVS
        administrative sub-directories and their contents.

      - If "CVS" (admin subdir's name) is specified explicitly it will be
        (silently unless -) ignored.

  - Variations of "newfile", "path/to/newfile", and "dirname" will be
    accepted simultaneously on the command-line (just as with other CVS

  - no explicitly named file or directory will ever be ignored, even if
    it would be ignored by the current "cvsignore" list (i.e. "-I !" is
    not necessary for explicitly specified names that would be otherwise
    ignored if they were simply implied by recursion)

I was reluctant to write the proposal this way and gave in only for the
case where the command line parameter is a directory name and thus would
trigger recursive operation.

We should have been happy with running "make distclean" before running
"cvs import".

> Why should users jump through hoops just to have CVS not do something they
> don't expect?

Because you can't have it both ways!!!!

The decision was made long ago and it has been happily accepted for many
years now.

> Not a valid argument when wildcards or xargs are in use.

Paul, please go back to basic unix school.  I.e. learn to use your tools
properly instead of abusing them!  Meanwhile here's how you should
remove all the object files in your source tree:

        find . -print | xargs rm

Please try it out and let me know how it works.

If you don't understand how and why wildcards work then don't use them!

                                                                Greg A. Woods

+1 416 218-0098;            <address@hidden>;           <address@hidden>
Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>

reply via email to

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