Re: git: uh-oh

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: git: uh-oh
Дата
Msg-id AANLkTi=kbKDDJPthk4ZvogxN29azRt3yNNVHzUnnmJAn@mail.gmail.com
обсуждение исходный текст
Ответ на Re: git: uh-oh  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: git: uh-oh  (Max Bowsher <maxb@f2s.com>)
Список pgsql-hackers
On Tue, Sep 7, 2010 at 7:18 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Well, as Max says downthread, cvs -r REL8_4_STABLE -d
>> INTERMEDIATE_DATE apparently shows the file as being there, which is a
>> fairly good argument for his position.
>
> I haven't tested, but if I understand what Max and Michael are saying
> about CVS, that operation would probably show the file as being there
> on *every* date between REL8_4_STABLE splitting off and the actual
> addition of it.po to the branch.  Because CVS isn't paying attention to
> the evidence of the intermediate tags not being there, either.
>
> Nonetheless, having the file pop into being and then disappear again
> between two observable points seems way too much like quantum physics
> for my taste.  I think it has to be possible for cvs2git to produce a
> less surprising translation.

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.  One thing I'm not quite clear on is
how cvs2git thinks CVS "should" look given what we actually did vs.
how it actually does look, but if our CVS repository is busted maybe
we should be looking to fix that rather than complaining about
cvs2git.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: git: uh-oh
Следующее
От: Tom Lane
Дата:
Сообщение: Re: "Freezing" per-role settings