2010/9/10 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
>> commit fd0c9e8bbf50f65a6d03a5d5d59e19cf67c7bc94 refs/tags/REL8_4_3
>> Author: Peter Eisentraut <peter_e(at)gmx(dot)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(at)postgresql(dot)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(at)gmx(dot)net> 'Translation updates for 9.0alpha4':
>> 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 18.104.22.168 revision to 22.214.171.124 (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.
"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.
In response to
pgsql-hackers by date
|Next:||From: Boszormenyi Zoltan||Date: 2010-09-10 09:14:41|
|Subject: Re: plan time of MASSIVE partitioning ...|
|Previous:||From: Magnus Hagander||Date: 2010-09-10 08:21:03|
|Subject: Re: git: uh-oh|