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.
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 |