Re: git: uh-oh

On Tue, Sep 7, 2010 at 8:54 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Max Bowsher <maxb(at)f2s(dot)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