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
> >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
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/,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                      
The PostgreSQL Company - Command Prompt, Inc.

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to