Re: git: uh-oh

On Fri, Aug 20, 2010 at 1:56 PM, Max Bowsher <maxb@f2s.com> wrote:
> My guess at this point is that there may be a (very old?) version of cvs
> which, when adding a file to a branch, actually misrecorded the file as
> having existed on the branch from the moment it was first added to trunk
> - this would explain this anomaly.

I think this is what is happening, except I'm unable to account for it
by the age of the CVS version we're runnning.  The machine the CVS
repo is running on is running 1.11.17-FreeBSD (client/server).  I
don't know how long it's been that way, but there are examples of this
in the relatively recent past - like July 2nd of this year.  I am 100%
positive that what I did was 'cvs add' one new file, 'cvs delete' one
old file, modify a few other things, and commit the whole deal.  But
in the git conversion there are two commits, one of which adds a copy
of the file as it exists in HEAD and the other of which contains the
balance of the changes.  Every recent manufactured commit is of this
same form: it immediately precedes the commit of which (in my view) it
should be considered a part.

Looking back a bit further in history, there is some stranger stuff.

commit ec0274633871c43da670fa90d0ac4fd7090639f2
Author: PostgreSQL Daemon <webmaster@postgresql.org>
Date:   Mon Jun 6 16:30:43 2005 +0000
   This commit was manufactured by cvs2svn to create branch 'REL8_0_STABLE'.
   Cherrypick from master 2005-06-06 16:30:42 UTC Bruce Momjian <bruce@momjian.       doc/src/FAQ/FAQ_hungarian.html

And then, much later, the following completely empty commit:

commit 446b749c2eaeff3c0611d33bc12b3df28e2cf8fa
Author: Bruce Momjian <bruce@momjian.us>
Date:   Tue Oct 4 14:17:44 2005 +0000
   Add FAQ_hungarian.html to 8.0.X branch.

What really happened is:

http://archives.postgresql.org/pgsql-committers/2005-10/msg00044.php

So that's pretty much the same thing, except the time lag between the
two commits that should be married is much larger.

The odder cases are the ones involving deletion.  There are a couple
of branches/tags that, or so I'm guessing, are only present for a
subset of the files in the repository: ecpg_big_bison, creation,
Release-1-6-0, MANUAL_1_0, REL2_0B, and SUPPORT.  I'm wondering if we
shouldn't just nuke those, or at least nuke them from the copy of the
repository upon which we are running the conversion.

This series of commits also seems pretty messed up:

http://archives.postgresql.org/pgsql-committers/2007-04/msg00222.php
http://archives.postgresql.org/pgsql-committers/2007-04/msg00223.php

The commit messages make it clear that CVS did something funky,
although it's not exactly clear retrospectively what it was.  At any
rate, it's evidently still not right, because in the converted
repository we get a whole slough of commits like this:

commit c50da22b6050e0bdd5e2ef97541d91aa1d2e63fb
Author: PostgreSQL Daemon <webmaster@postgresql.org>
Date:   Sat Dec 2 08:36:42 2006 +0000
   This commit was manufactured by cvs2svn to create branch 'REL8_2_STABLE'.
   Sprout from master 2006-12-02 08:36:41 UTC PostgreSQL Daemon <webmaster@post   Delete:
src/backend/parser/gram.c      src/interfaces/ecpg/preproc/pgc.c       src/interfaces/ecpg/preproc/preproc.c
 

There are similar (but separate) commits for tag REL8_2_RC1,
REL8_2_BETA3, REL8_2_BETA2, REL8_2_BETA1, REL8_1_STABLE, REL8_1_0_RC1,
REL8_1_0BETA4, REL8_1_0BETA3, REL8_1_0BETA2, REL8_1_0BETA1, REL8_0_0,
REL8_0_0RC5, REL8_0_0RC4, REL8_0_0RC3, REL8_0_0RC2, REL8_0_0RC1,
REL8_0_0BETA5, REL8_0_0BETA4, REL8_0_0BETA3, REL8_0_0BETA2,
REL8_0_0BETA1, REL7_4_STABLE, REL7_4_BETA5, REL7_4_BETA4,
REL7_4_BETA3, REL7_4_BETA2, REL7_4_BETA1, REL7_2_STABLE, REL7_2,
REL7_2_RC2, REL7_2_RC1, REL7_2_BETA5, REL7_2_BETA4, REL7_2_BETA3,
REL7_2_BETA2, REL7_2_BETA1, REL7_1_STABLE, REL7_1_BETA3, REL7_1_BETA2,
REL7_0_PATCHES, REL7_0, REL6_5_PATCHES, and release-6-3.  That's
pretty crazy.  I think we should try to do something to clean this up,
perhaps by doctoring the file on the CVS side.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company