Re: git: uh-oh

2010/9/10 Tom Lane <tgl@sss.pgh.pa.us>:
> I wrote:
>> OK, so I tried a conversion with the it.po hack I showed before; not
>> trying to fix any of the other instances yet, but just see what happens
>> with the 8.4.3/8.4.4 case.  It's definitely better:
>
>> * Marc's 8.4.3 tag commit is now the last ancestor of REL8_4_3, and the
>> previous commits in the branch are earlier ancestors.  No more 8.4.3
>> as a stub branch.
>
>> * it.po is shown as added, not modified, in Peter's 8.4-branch commit
>> of 2010-05-13.
>
>> * The cherrypick additions of xml2.out and xml2.sql no longer reference
>> it.po too.
>
>> But we're not quite there yet.  What I find for it.po is these two
>> commits, which immediately follow the addition of it.po on the main
>> branch:
>
>
>> commit fd0c9e8bbf50f65a6d03a5d5d59e19cf67c7bc94       refs/tags/REL8_4_3
>> Author: Peter Eisentraut <peter_e@gmx.net>
>> Date:   Fri Feb 19 00:40:07 2010 +0000
>
>>     log addition on branch
>
>> D     src/bin/pg_dump/po/it.po
>
>> commit f345298286359f666211c7555420d147222888bf       refs/tags/REL8_4_3
>> Author: PostgreSQL Daemon <webmaster@postgresql.org>
>> Date:   Fri Feb 19 00:40:06 2010 +0000
>
>>     This commit was manufactured by cvs2svn to create branch 'REL8_4_STABLE'.
>
>>     Cherrypick from master 2010-02-19 00:40:05 UTC Peter Eisentraut <peter_e@gmx.net> 'Translation updates for
9.0alpha4':
>>         src/bin/pg_dump/po/it.po
>
>> A     src/bin/pg_dump/po/it.po
>
>
> After some more experimentation I believe I've found the answer: what we
> should do is hack the CVS history so that the branch revisions sprout
> from the mainline revision that they should logically have sprouted
> from, not the chronologically-most-recent revision.  When I modify it.po
> as shown in the attached patch, I get a conversion that has no funny
> business at all: it.po is deleted where it should be, and added where it
> should be, and there's *no* manufactured commit anywhere.
>
> Now, when you look at the patch, it's probably going to scare the
> daylights out of you.  But it's really not that bad.  What we're doing
> is renumbering the 1.7.6.1 revision to 1.5.6.1 (because it now sprouts
> from 1.5 not 1.7 on the mainline) and replacing its delta content with
> an appropriate delta from 1.5 not 1.7.  The delta content is easily
> generated via "cvs diff -n" between the relevant versions --- AFAICT
> all we have to do to the diff output is double any @-signs.  We can also
> easily verify that we did it right, by checking out the branch revision
> from CVS afterwards and seeing that it has the right content.
>
> Once I understood what needed to be done, it took me about two minutes
> to make these changes manually.  I'm inclined to think it's not worth
> developing a tool for it --- we could probably manually fix the couple
> dozen files that need to be fixed in less time than that would take.
>
> Comments?

"That patch scares the daylights out of me"? ;)

Anyway, yeah, it does seem like a good way to do it. If we can produce
a patch that we apply to the raw cvs repository before we do the
migration, that's good - but I would like to avoid the manual steps in
the *actual migration*. Once we do the final migration, it should just
be a replay of the exact same steps we used for the final testing
repository, which is hard to guarantee if we need to set this up
manually each time.


--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/