Re: Hacking on PostgreSQL via GIT

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Hacking on PostgreSQL via GIT
Дата
Msg-id 12781.1176771422@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Hacking on PostgreSQL via GIT  (Aidan Van Dyk <aidan@highrise.ca>)
Ответы Re: Hacking on PostgreSQL via GIT  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Hacking on PostgreSQL via GIT  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
Aidan Van Dyk <aidan@highrise.ca> writes:
> * Tom Lane <tgl@sss.pgh.pa.us> [070416 19:03]:
>> I like the idea of re-adding and then re-removing the files on HEAD.
>> Does anyone think that poses any real risk?

> No - it even fixed the "hand moved" test I had done trying to create an
> Attic with, when trying to figure out how they got that way in the first
> place...

Well, it doesn't work :-(.  CVS is definitely a bit confused about the
status of these files:

$ touch gram.c
$ cvs add gram.c
cvs add: gram.c added independently by second party
$ cvs remove gram.c
cvs remove: file `gram.c' still in working directory
cvs remove: 1 file exists; remove it first
$ rm gram.c
rm: remove regular empty file `gram.c'? y
$ cvs remove gram.c
cvs remove: nothing known about `gram.c'

So there's no way, apparently, to fix the state of these files through
the "front door".  Shall we try the proposed idea of hand-moving the
files out of the Attic subdirectory, whereupon they should appear live
and we can cvs remove them again?  I have login on cvs.postgresql.org
and can try this, but I'd like confirmation from someone that this is
unlikely to break things.  Is there any hidden state to be fixed in the
CVS repository?  I don't see any ...
        regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: RESET command seems pretty disjointed now
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Hacking on PostgreSQL via GIT