Re: CVS corruption/mistagging?

I wrote:
> I did a fresh checkout of the 7.4 branch and diff'd against my local
> copy, and it seems clear that every file that was not in 7.4 at all has
> had its HEAD version tagged as REL7_4_STABLE. The files that did exist
> then are all right. That's throughout the whole tree, not just in
> contrib/btree_gist.

As for getting out of it: it looks like the misapplied tags are revision
tags not branch tags, eg

RCS file: /cvsroot/pgsql/contrib/btree_gist/btree_bit.c,v
Working file: btree_bit.c
head: 1.7
branch:
locks: strict
access list:
symbolic names:
REL7_4_STABLE: 1.7 <--- wrong
REL8_0_13: 1.2
REL8_1_9: 1.6
REL8_2_4: 1.6
REL8_0_12: 1.2
REL8_1_8: 1.6
REL8_2_3: 1.6
REL8_0_11: 1.2
REL8_1_7: 1.6
REL8_2_2: 1.6
REL8_0_10: 1.2
REL8_1_6: 1.6
REL8_2_1: 1.6
REL8_2_STABLE: 1.6.0.4

which I think means that there's a one-liner way out of it. The CVS
manual quoth:

To delete a tag, specify the `-d' option to either `cvs tag' or `cvs
rtag'. For example:

cvs rtag -d rel-0-4 tc

deletes the non-branch tag `rel-0-4' from the module `tc'. In the
event that branch tags are encountered within the repository with the
given name, a warning message will be issued and the branch tag will
not be deleted. If you are absolutely certain you know what you are
doing, the `-B' option may be specified to allow deletion of branch
tags. In that case, any non-branch tags encountered will trigger
warnings and will not be deleted.

So I think that "cvs rtag -d REL7_4_STABLE pgsql" will fix it.
I'd like someone to double-check that though. Also maybe we should back
up the repository first?

regards, tom lane