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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq