On 07/09/10 23:15, Robert Haas wrote:
> On Tue, Sep 7, 2010 at 5:47 PM, Tom Lane <tgl@sss.pgh.pa.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.
Max.