Re: git: uh-oh

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: git: uh-oh
Дата
Msg-id 16286.1283907244@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: git: uh-oh  (Max Bowsher <maxb@f2s.com>)
Ответы Re: git: uh-oh  (Robert Haas <robertmhaas@gmail.com>)
Re: git: uh-oh  (Michael Haggerty <mhagger@alum.mit.edu>)
Список pgsql-hackers
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.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: git: uh-oh
Следующее
От: Robert Haas
Дата:
Сообщение: Re: git: uh-oh