Re: Hacking on PostgreSQL via GIT
От | Andrew Dunstan |
---|---|
Тема | Re: Hacking on PostgreSQL via GIT |
Дата | |
Msg-id | 46241F2B.5070602@dunslane.net обсуждение исходный текст |
Ответ на | Re: Hacking on PostgreSQL via GIT (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Hacking on PostgreSQL via GIT
|
Список | pgsql-hackers |
Tom Lane wrote: > 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 ... > > Forgive my caution, but I'd suggest trying on a copy first. cheers andrew
В списке pgsql-hackers по дате отправления: