Re: CVS corruption/mistagging?

I wrote:
> Kris Jurka <books(at)ejurka(dot)com> writes:
>> It looks like parts of the CVS repository have been mistagged as belonging
>> to REL7_4_STABLE or have been corrupted somehow:
>> http://developer.postgresql.org/cvsweb.cgi/pgsql/contrib/btree_gist/btree_bit.c?sortby=date;only_with_tag=REL7_4_STABLE

> Hmm ... btree_bit.c shouldn't be in 7.4 at all.

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. I have no idea how you make CVS do that, but I'm
sure there is some magic one-liner for it.

Checking the files in contrib/btree_gist on the CVS server gives a
pretty good fix on who changed it and when:

> ls -la
total 466
drwxrwxr-x 6 scrappy dev 1024 Aug 14 22:30 .
drwxrwxr-x 90 scrappy dev 2048 Aug 14 22:27 ..
drwxrwxr-x 2 scrappy dev 512 Apr 20 15:16 Attic
-r--r--r-- 1 tgl dev 9555 Jun 26 22:05 Makefile,v
-r--r--r-- 1 258 dev 5870 Apr 20 16:19 README.btree_gist,v
-r--r--r-- 1 meskes dev 12052 Aug 12 09:50 btree_bit.c,v
-r--r--r-- 1 meskes dev 9921 Aug 12 09:50 btree_bytea.c,v
-r--r--r-- 1 meskes dev 10246 Aug 12 09:50 btree_cash.c,v
-r--r--r-- 1 meskes dev 11433 Aug 12 09:50 btree_date.c,v
-r--r--r-- 1 meskes dev 10230 Aug 12 09:50 btree_float4.c,v
-r--r--r-- 1 meskes dev 10093 Aug 12 09:50 btree_float8.c,v
-r--r--r-- 1 meskes dev 33935 Aug 12 09:50 btree_gist.c,v
-r--r--r-- 1 258 dev 4325 Apr 20 15:16 btree_gist.h,v
-r--r--r-- 1 258 dev 58744 Apr 20 16:19 btree_gist.sql.in,v
-r--r--r-- 1 meskes dev 14736 Aug 12 09:50 btree_inet.c,v
-r--r--r-- 1 meskes dev 10253 Aug 12 09:50 btree_int2.c,v
-r--r--r-- 1 meskes dev 10240 Aug 12 09:50 btree_int4.c,v
-r--r--r-- 1 meskes dev 10254 Aug 12 09:50 btree_int8.c,v
-r--r--r-- 1 meskes dev 18111 Aug 12 09:50 btree_interval.c,v
-r--r--r-- 1 meskes dev 12025 Aug 12 09:50 btree_macaddr.c,v
-r--r--r-- 1 meskes dev 14671 Aug 12 09:50 btree_numeric.c,v
-r--r--r-- 1 meskes dev 9796 Aug 12 09:50 btree_oid.c,v
-r--r--r-- 1 meskes dev 18247 Aug 12 09:50 btree_text.c,v
-r--r--r-- 1 meskes dev 26180 Aug 12 09:50 btree_time.c,v
-r--r--r-- 1 258 dev 29712 Apr 20 15:16 btree_ts.c,v
-r--r--r-- 1 meskes dev 17588 Aug 12 09:50 btree_utils_num.c,v
-r--r--r-- 1 meskes dev 8959 Aug 12 09:50 btree_utils_num.h,v
-r--r--r-- 1 meskes dev 48824 Aug 12 09:50 btree_utils_var.c,v
-r--r--r-- 1 meskes dev 7099 Aug 12 09:50 btree_utils_var.h,v
drwxrwxr-x 3 scrappy dev 1024 Aug 14 22:27 data
drwxrwxr-x 3 scrappy dev 1024 Aug 14 22:27 expected
drwxrwxr-x 3 scrappy dev 1024 Aug 14 22:27 sql
-r--r--r-- 1 meskes dev 10021 Aug 12 09:50 uninstall_btree_gist.sql,v

Michael, want to fess up to what you did?

In the meantime, though, it's not quite clear why this would lead to
a buildfarm failure --- it should just mean a lot of extraneous files
appearing in a fresh checkout. (Looks a bit harder ... Oh, it looks
like btree_gist has some files that used to be autogenerated and are
now in CVS, so the bogusly new versions from CVS are suppressing the
desired generation from the old btree_num.c file.)

regards, tom lane