Re: .cvsignore file being ignored

[Mark D. Baushke]

Paul Sander <address@hidden> writes:

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

Yes, that 'cvs import' obeys the .cvsignore file is somewhat broken.
The '-I !' command-line option should be honored and should NOT process
either local .cvsignore files or the global CVSROOT/cvsignore file), but
it too late to fix it now...

The big thing to remember that is different between cvs import and cvs add
is that an import happens immediately while an add does not happen until
the 'cvs commit' occurs and any time up until the 'cvs commit' you may
remove files from the list of those that should not be committed.

In an different world perhaps only the new directories would be added to
the repository on a 'cvs import' and the import tree would become a
sandbox with all of the files having been 'added' to the repository, but
not yet committed. That different world might allow folks to make sure
that their master repository still worked properly with all of the new
imported files... Ah well, that is not this world today.

The way that 'cvs import' works was made long ago and a change to it
will not likely happen even though there is some merit in the fact that
a cvs import may appear to do the 'wrong' thing when some files have
local changes and others are unchanged after a cvs import occurs that
makes some of those new files visible, but not all of them. (I am still
pondering the order of an import versus work on a branch problem raised
in a different thread.)

In general, best practice would have you add a local change to all of
the imported files so that nothing on your HEAD would change when you
did the import until after you had merged all of the changes forward to
the HEAD... not everyone likes that methodology, so that is probably not
what folks do today...

> 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.

In theory, a user can type 'cvs import -I !' and have *all* of the files
imported... well, as long as they remove all of their .cvsignore files
first and emasculate any CVSROOT/cvsignore files. How do you proposed that
'cvs add' users get ALL of they files they explicitly request be added to
the repository added? Mind reading software is notoriously slow to get
into production for some reason.

> - 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.

I find this idea of an interface to be ugly...

> - The "cvs add" command provides an option to ignore the contents of the
>   .cvsignore file, just as "cvs import" does.
 
> 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.

This sounds like an education problem to me. If you tell them that
whatever they put on the 'cvs add' command line will be added to the
repository, and that is what the command does, won't they expect that
behavior?

CVS is NOT configured to ignore .o .a and whatever types of files. It is
configured to suppress complaining about them when they are found in a
controlled directory.

> >--- Forwarded mail from Greg Woods:
> >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.

But the point is that any argument to cvs add is valid. That is what we
have been saying all along...

If I need/want to do

   cvs add lib-a-purchased-library.a

to add a .a file obtained from a third party to my sources, why should
cvs ignore that I have done this? The cvs command is not able to
distinguish this from the

   cvs add *.a

command in a directory which contains only the single
lib-a-purchased-library.a file.

> >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.

Certainly, the software is not immutable. 

You yourself have the sources and therefore the ability to do anything
you wish to them. I have no problems with you choosing to do anything
you wish to your copy of the sources and I encourage you to make the
changes you believe will improve the product and deploy them into your
environment for testing and production. Feel free to update your sources
as often as you wish out of the cvshome.org repository or periodic
source distributions.

If your patch is particularly elegant and desirable, who knows, someone
may add it to the repository for you.

However, you may find your time is better used if you go and use
Meta-CVS instead of vanilla CVS. It appears to already have the feature
you desire and Kaz Kylheku has been very responsive to problem reports
and keeping his extra features working even when CVS changes.

> It can, and should, be changed if ease of use is increased, provided
> no utility is lost. 

Okay, I assert that utility is lost. Other tools out there that work on
top of cvs depend on 'cvs add' not being as silly about actually doing
what they tell it to do as the 'cvs import' command.

Adding a feature that does what you want does not seem that simple to me
and would need to default off to start, so I expect it would be more
complicated that is desirable for the code base. I could be wrong. Write
the code and prove it if you hold a contrary opinion. Then write all of
the test cases to deal with the use of the new feature and how it
interacts with the rest of the system.

> Justifying a broken UI because "that's just the
> way it works" is nonsense.

Yes. I agree, if that was the only reason to justify the decision, it
would be nonsense.

However, I do not believe I have heard that as the only justification
for the current mechanism. I have read a lot of what Larry and Greg have
written and in this case I do not see a pressing need for another option
to the cvs add command that changes its behavior incompatibly.

If we are talking enhancements to the add command, I would be more
likely to go for the idea of a recursive add of a new sub-directory and
its contents. If this buys you a way to do what you want done AND as a
new feature that does not directly impinge on the existing behavior,
then something like that might just make it into the experimental
branch to see how folks liked it.

An e-mail thread which devolves to an shouting match of one opinion
against another does not really impress me with the relative merits of
the new proposition. All it does it reinforce the idea of strong
opposition to a particular change... there are so many features and
fixes that CVS could be enhanced to use, why spend time on one that is
controversial?

That said, my time to implement new features is limited and biased
toward what I consider useful and interesting to code. If someone else
wants to pound out a new feature and some test cases and it gets some
general support, it would be more likely to be considered.

For my own purposes, I would like to see the features that exist in the
cvs available from FreeBSD, OpenBSD, NetBSD and CVSNT and do not yet
exist in CVS get merged as much as possible into CVS. Some may take
longer than others, but if one needs a goal, that one is not too bad.

        Enjoy!
        -- Mark