Re: cvs problems ...

[Zack Weinberg <zack@codesourcery.com>]

Since it doesn't look like a fix for the underlying bug is coming in
short order, I'd like to suggest a custom for ensuring that the
repository gets restored to a usable state as fast as possible.

Whenever anyone does a merge of any kind, or hits ^C on a commit
operation, they should IMMEDIATELY AFTERWARD perform a cvs update from
a separate checkout of the trunk.  If this fails, they should
immediately notify overseers@sources.redhat.com, giving the full text
of the error message.  They should also mention the problem on the IRC
channel #gcc on irc.oftc.net, if possible.  (I do not want to force
people to use IRC if they aren't already familiar with it.  However,
that channel may well be a faster way to raise someone who knows how
to fix the problem.)

In other words, it is the responsibility of the person who did the
operation that might break CVS to find out if they broke CVS, and if
so, to notify someone who can fix it.

----

Fixing CVS requires shell access to gcc.gnu.org/sources.redhat.com and
write privileges on the repository that's busted.  I will outline what
one does, but caution everyone that this is fiddly and somewhat
dangerous - if you're not confident that you will not clobber the
wrong files, please leave it to the sysadmins.

The error message indicates the directory with a broken fileattr
cache, e.g.

> > cvs [update aborted]: branch attribute does not match file 
> > for `/cvs/gcc/gcc/boehm-gc/NT_STATIC_THREADS_MAKEFILE,v'

The specific ,v file is irrelevant - it's just the first file that CVS
tried to access in the directory with the bad cache.  What you do when
you see this is

sourceware $ cd /cvs/gcc/gcc/boehm-gc
sourceware $ : > CVS/fileattr

The effect of that odd all-punctuation command is to truncate the file
to length zero, but leave its inode untouched.  This is important,
because the file has to be owned by the 'anoncvs' user.  If you delete
it, it will get recreated by the next person to access the repository,
with the wrong ownership.  [In case you would be more comfortable with
a longer but less cryptic command, "cp /dev/null CVS/fileattr" also
works.]

Then you immediately try to do a cvs update again.  Odds are that
it will throw the same error with a different pathname.  Truncate that
directory's CVS/fileattr too.  Repeat until the update succeeds.

zw