[ 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 traversal. 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 commands). - 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; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs