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
Re: Hacking on PostgreSQL via GIT |
Список | 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 по дате отправления: