Re: .cvsignore file being ignored

[Paul Sander]

>--- 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 address@hidden