Andrew Dunstan wrote: > Tom Lane wrote: > >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.
Too late ;-) FWIW my CVSup copy seems happy with the change; it reported this when I updated it: $ pgcvsup Connected to cvsup.postgresql.org Updating collection repository/cvs Edit pgsql/src/backend/parser/gram.c,v -> Attic Edit pgsql/src/backend/utils/mb/encnames.c,v Edit pgsql/src/bin/pg_dump/pg_dump.c,v Edit pgsql/src/bin/psql/common.c,v Edit pgsql/src/include/pg_config.h.win32,v Edit pgsql/src/interfaces/ecpg/preproc/pgc.c,v -> Attic Edit pgsql/src/interfaces/ecpg/preproc/preproc.c,v -> Attic Edit pgsql/src/tools/msvc/Solution.pm,v Rsync sup/repository/checkouts.cvs Finished successfully The gram.c,v file looks good -- it has the expected "state dead;" line. A checked out tree from that updates fine. A "cvs update" to a checked out tree direct from the main CVS server also updates fine. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
