On Tue, Sep 7, 2010 at 8:54 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Max Bowsher <m...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
