.cvsignore doesn't work for removed files on a branch

[Stephen McCamant]

[This is similar to a message I sent last week to info-cvs, but I
didn't see it in the archive, so I think it might have fallen into a
moderation black-hole. Apologies if you get multiple copies.]

I've run into an issue with CVS similar to one that was reported in
November ("CVS won't ignore removed files (remote will, local will
not)"
http://mail.gnu.org/archive/html/info-cvs/2002-11/msg00326.html).

Here's the situation: we have a file that was once a source file, but
is now automatically generated from another file during the build. It
used to be in the CVS repository, but now it's been "cvs remove"d, and
its name has been added to the .cvsignore file in the directory where
it lives.

For the main version of the repository, the .cvsignore file works as
desired: "cvs update" doesn't show any messages related to the
file. On a branch, however, I still see messages like:

cvs update: use `cvs add' to create an entry for foo

(where "foo" is the name of the file, no longer in the repository but
still in the working directory).

Testing with a local repository, I see this problem with both 1.11.1p1
(from RedHat) and a freshly downloaded 1.11.5.

Looking at the source code, it appears that the problem occurs because
this message is generated in Classify_File(), which doesn't check the
list of files to ignore. The reason this problem doesn't occur on the
head appears to be that the RCS file has moved into the "Attic"
subdirectory in the repository, which is only searched when a date or
tag is specified (implicitly, in the case of our branch).

The patch appended to this message represents a potential approach to
fixing the problem. I've added a call to ign_name() right before the
message, and disabled printing it if the file is in .cvsignore. In
order for this to work properly with per-directory .cvsignore files
(which is what we're using), I also had to move the call that reads
the .cvsignore file to the beginning rather than the end of processing
for that directory. I haven't carefully tested this patch, but it
should convey the basic idea of a possible fix.

Is this a correct diagnosis of the problem? Can anyone see a clean way
to work around it, other than changing CVS? (Obviously I could write a
wrapper around cvs, or I could rename the old RCS file in the
repository, but neither of those seem appealing).

Thanks in advance for any suggestions,

 -- Stephen

--- classify.c.orig     Tue Apr  8 14:40:29 2003
+++ classify.c  Tue Apr  8 14:51:21 2003
@@ -77,6 +77,9 @@
            /* there is an RCS file, but it's dead */
            if (vers->ts_user == NULL)
                ret = T_UPTODATE;
+           else if (ign_name(finfo->file))
+               /* avoid a message if the user is ignoring the file */
+               ret = T_UPTODATE;
            else
            {
                error (0, 0, "use `%s add' to create an entry for %s",
--- ignore.c.orig       Tue Apr  8 14:40:34 2003
+++ ignore.c    Tue Apr  8 14:40:47 2003
@@ -405,7 +405,6 @@
        return;
     }
 
-    ign_add_file (CVSDOTIGNORE, 1);
     wrap_add_file (CVSDOTWRAPPER, 1);
 
     /* Make a list for the files.  */
--- recurse.c.orig      Sat Dec 28 13:01:30 2002
+++ recurse.c   Tue Apr  8 14:46:33 2003
@@ -732,6 +732,9 @@
        frfile.finfo = &finfo_struct;
        frfile.frame = frame;
 
+       /* Load .cvsignore file */
+       ign_add_file (CVSDOTIGNORE, 1);
+
        /* process the files */
        err += walklist (filelist, do_file_proc, &frfile);