Re: git: uh-oh

From: Max Bowsher <maxb(at)f2s(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: git: uh-oh
Date: 2010-09-07 22:34:31
Message-ID: 4C86BDF7.5050609@f2s.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 07/09/10 23:20, Max Bowsher wrote:
> On 07/09/10 23:15, Robert Haas wrote:
>> On Tue, Sep 7, 2010 at 5:47 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> BTW, why is this commit shown as being a predecessor of refs/tags/REL8_4_4
>>> and not refs/tags/REL8_4_3? That's nothing to do with it.po, perhaps,
>>> but it sure looks wrong. (Magnus, did you check against the 8.4.3 tarball?)
>>
>> I think this is another result of the same basic problem. Since
>> cvs2git thinks it.po was added to REL8_4_STABLE on 2010-02-28 rather
>> than 2010-05-13,the REL8_4_STABLE version that existed on to
>> 2010-03-12, when 8.4.3 was tagged, includes that file. But cvs2git
>> also knows that 8.4.3 does NOT include that file, so it picks the
>> commit on the 8.4.3 branch that most closely matches the contents of
>> the tag (namely, Marc's "tag 8.4.3" commit) and then shoves a
>> manufactured commit on top of that to make the contents of the 8.4.3
>> tag match what actually got tagged. But that manufactured commit is
>> only there to make the tag contents match; it's not actually part of
>> the branch. If the conversion correctly made it.po get added on
>> 2010-05-13 rather than 2010-02-28 then Marc's "tag 8.4.3" commit would
>> match the tag contents exactly and no manufactured commit would be
>> created.
>
> Yes, this is the correct analysis.
>
>> The effect of all of this is that if someone checks out a git commit
>> between 2010-02-28 and 2010-05-13, it.po will be there, even though
>> file didn't exist on that CVS branch at that time. Max's contention
>> seems to be that this is a CVS problem rather than a cvs2git problem.
>> Perhaps we can do something like cvs update -r REL8_4_STABLE -d
>> SOME_INTERMEDIATE_DATE and see whether that file is there or not.
>
> $ cvs co -r REL8_4_STABLE -D "2010-04-01" pgsql
> ...
> $ ls -la pgsql/src/bin/pg_dump/po/it.po
> -rw-r--r-- 1 maxb maxb 67871 2010-02-19 00:40 pgsql/src/bin/pg_dump/po/it.po
>
> It's there.

And, I've just tracked down that this bug was apparently fixed in CVS
1.11.18, released November 2004.

Max.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-09-07 22:52:27 Re: git: uh-oh
Previous Message Tom Lane 2010-09-07 22:34:02 Re: git: uh-oh