On Tue, Sep 7, 2010 at 8:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Max Bowsher <maxb@f2s.com> writes:
>> On 08/09/10 00:37, Robert Haas wrote:
>>> Well, if Max is correct that this bug is fixed in CVS 1.11.18 (I don't
>>> see it in the NEWS file) and that a checkout-by-date shows the file
>>> present during the time cvs2git claims it is present, then a less
>>> surprising translation wouldn't be a faithful representation of the
>>> contents of our CVS repository.
>
>> Correct. You'll have to decide whether you wish to represent your
>> current cvs repository, or attempt to doctor things to fix the insanity
>> CVS introduced.
>
> Well, even if the goal is to faithfully represent the bogus history
> shown by CVS, cvs2git isn't doing a good job of it. In the case of
> src/bin/pg_dump/po/it.po, the CVS history claims that the version
> added to REL8_4_STABLE on 2010-05-13 is a child of the mainline
> version 1.7 committed on 2010-02-19. Therefore, according to CVS
> the file existed on the branch from 2010-02-19, not 2010-02-28
> as claimed by the cvs2git translation. I did some "cvs co" operations
> to check this and cvs does indeed retrieve the file between 02-19 and
> 02-28, but not before 02-19. So I don't think you can defend the
> cvs2git behavior by claiming that it's an exact translation.
>
> Right at the moment, though, I'm more interested in the idea of
> patching the CVS repository to make the problem go away.
If we decide we're actually going to fix this problem, then I think
the definition of "fixed" should be that every tag of the form
RELx_y_z is an ancestor of the branch RELx_y_STABLE. Maybe it would
be worth writing a sanity check along those lines.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
