CVS corruption/mistagging?
in [PgSql]
|
Prev: Bug: Buffer cache is not scan resistant
Next: CREATE DATABASE cannot be executed from a function or multi-command string
From: Tom Lane on 14 Aug 2007 19:03 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
From: Andrew Dunstan on 14 Aug 2007 20:33 Tom Lane wrote: > > So I think that "cvs rtag -d REL7_4_STABLE pgsql" will fix it. > I'd like someone to double-check that though. I will test on a copy of my mirror. > Also maybe we should back > up the repository first? > Amen. cheers andrew ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
From: Andrew Dunstan on 14 Aug 2007 20:54 Andrew Dunstan wrote: > > > Tom Lane wrote: >> >> So I think that "cvs rtag -d REL7_4_STABLE pgsql" will fix it. >> I'd like someone to double-check that though. > > I will test on a copy of my mirror. > I copied the mirror, did a checkout from it, ran the command above in the checked out version, then remove my checkout and checked out REL7_4_STABLE and did a diff against my copy from the postgres repo that hasn't been updated for some time. There were no significant differences, and no extra files. So I'd say your strategy looks good - backup and remove the phony tag. I'd also say we should probably be logging tag commands in taginfo. Presumably we mere mortal committers should not be doing any tagging whatsoever, and tags should only be applied in preparation for releases. Anyway, if we actually logged it we'd catch anything untoward early rather than possibly days later. cheers andrew ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
From: Tom Lane on 14 Aug 2007 22:20 Andrew Dunstan <andrew(a)dunslane.net> writes: > So I'd say your strategy looks good - backup and remove the phony tag. > I'd also say we should probably be logging tag commands in taginfo. > Presumably we mere mortal committers should not be doing any tagging > whatsoever, and tags should only be applied in preparation for releases. +1 ... we should at least log such commands, and maybe disallow to anyone except Marc's "pgsql" account. Particularly since they don't get reported in pgsql-committers messages (or is that something we can/should change?) Meanwhile, is there anyone around who can either (1) tar up the repository directory tree as root, or (2) confirm that a tarball made by a non-root committer is sufficient? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo(a)postgresql.org so that your message can get through to the mailing list cleanly
From: "Marc G. Fournier" on 14 Aug 2007 22:53
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --On Tuesday, August 14, 2007 22:20:16 -0400 Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > +1 ... we should at least log such commands, and maybe disallow to anyone > except Marc's "pgsql" account. Particularly since they don't get > reported in pgsql-committers messages (or is that something we > can/should change?) > > Meanwhile, is there anyone around who can either (1) tar up the > repository directory tree as root, or (2) confirm that a tarball > made by a non-root committer is sufficient? I've just finished tar'ng up the cvs repository as root ... I believe one as a non-root would be sufficient also, since it *should* retain file ownership / permissions with the -p option ... cvs# ls -lt cvsroot.aug14_2007.tar.bz2 - -rw-r--r-- 1 root wheel 62555651 Aug 15 02:52 cvsroot.aug14_2007.tar.bz2 cvs# du -sk cvsroot 414406 cvsroot - ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy(a)hub.org MSN . scrappy(a)hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFGwmq14QvfyHIvDvMRAsyFAJ9AND3JTDmOMR48Hl3Fdse2lVCjSwCglsu1 Pxj1LPPPx311rpY2XFj+Kvo= =Gz6E -----END PGP SIGNATURE----- ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend |