>--- Forwarded mail from Greg Woods: >[ On Thursday, June 5, 2003 at 14:00:12 (-0700), Kaz Kylheku wrote: ] >> Subject: Re: .cvsignore file being ignored >> >> I think that .cvsblock is silly; the tiny semantics difference between >> that and .cvsignore is not worth it. The cvs add command should ignore >> things that match .cvsignore, period.
>Because it was decided long ago that "cvs add" would be how all files >would be tagged for adding to the repository, including those that would >otherwise be ignored by default. 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. Consider the use of "cvs import", which obeys the .cvsignore file. From and end-user perspective, it's not unreasonable to expect the following: - CVS behaves the same way with regard to processing the .cvsignore file during both add and import. - CVS gives warnings or errors when a file named on the command line is omitted due to the .cvsignore file. Ideally, it would issue errors and leave the Entries file alone. - The "cvs add" command provides an option to ignore the contents of the .cvsignore file, just as "cvs import" does. >> Those who disagree: what part of >> ``cvs'' and ``ignore'' isn't clear? >What part of "Do What I Say!" don't you understand? CVS just does >exactly, and only, what you're telling it to do when you give it a file >or a list of files on the command line. Why should users have to jump >through extra hoops just to cause CVS to do what they're trying to tell >it to do in the first place? Why should users jump through hoops just to have CVS not do something they don't expect? If users are told that CVS is configured to ignore .o, .a, and whatever types of files, then CVS should do just that. It should not just sometimes ignore them. >If you don't want to add a file then do not include its name on the "cvs >add" command line!!!!! Not a valid argument when wildcards or xargs are in use. >This basic UI decision is part of history now. Like it or lump it. The fact that a feature is implemented in a certain way does not make it immutable. It can, and should, be changed if ease of use is increased, provided no utility is lost. Justifying a broken UI because "that's just the way it works" is nonsense. >--- End of forwarded message from [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
