Re: git: uh-oh

Поиск
Список
Период
Сортировка
От Max Bowsher
Тема Re: git: uh-oh
Дата
Msg-id 4C86BDF7.5050609@f2s.com
обсуждение исходный текст
Ответ на Re: git: uh-oh  (Max Bowsher <maxb@f2s.com>)
Ответы Re: git: uh-oh  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 07/09/10 23:20, Max Bowsher wrote:
> On 07/09/10 23:15, Robert Haas wrote:
>> On Tue, Sep 7, 2010 at 5:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> BTW, why is this commit shown as being a predecessor of refs/tags/REL8_4_4
>>> and not refs/tags/REL8_4_3?  That's nothing to do with it.po, perhaps,
>>> but it sure looks wrong.  (Magnus, did you check against the 8.4.3 tarball?)
>>
>> I think this is another result of the same basic problem.  Since
>> cvs2git thinks it.po was added to REL8_4_STABLE on 2010-02-28 rather
>> than 2010-05-13,the REL8_4_STABLE version that existed on to
>> 2010-03-12, when 8.4.3 was tagged, includes that file.  But cvs2git
>> also knows that 8.4.3 does NOT include that file, so it picks the
>> commit on the 8.4.3 branch that most closely matches the contents of
>> the tag (namely, Marc's "tag 8.4.3" commit) and then shoves a
>> manufactured commit on top of that to make the contents of the 8.4.3
>> tag match what actually got tagged.  But that manufactured commit is
>> only there to make the tag contents match; it's not actually part of
>> the branch.  If the conversion correctly made it.po get added on
>> 2010-05-13 rather than 2010-02-28 then Marc's "tag 8.4.3" commit would
>> match the tag contents exactly and no manufactured commit would be
>> created.
>
> Yes, this is the correct analysis.
>
>> The effect of all of this is that if someone checks out a git commit
>> between 2010-02-28 and 2010-05-13, it.po will be there, even though
>> file didn't exist on that CVS branch at that time.  Max's contention
>> seems to be that this is a CVS problem rather than a cvs2git problem.
>> Perhaps we can do something like cvs update -r REL8_4_STABLE -d
>> SOME_INTERMEDIATE_DATE and see whether that file is there or not.
>
> $ cvs co -r REL8_4_STABLE -D "2010-04-01" pgsql
> ...
> $ ls -la pgsql/src/bin/pg_dump/po/it.po
> -rw-r--r-- 1 maxb maxb 67871 2010-02-19 00:40 pgsql/src/bin/pg_dump/po/it.po
>
> It's there.


And, I've just tracked down that this bug was apparently fixed in CVS
1.11.18, released November 2004.

Max.


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

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