Re: Hacking on PostgreSQL via GIT - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Hacking on PostgreSQL via GIT
Date
Msg-id 12781.1176771422@sss.pgh.pa.us
Whole thread Raw
In response to Re: Hacking on PostgreSQL via GIT  (Aidan Van Dyk <aidan@highrise.ca>)
Responses Re: Hacking on PostgreSQL via GIT  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Hacking on PostgreSQL via GIT  (Andrew Dunstan <andrew@dunslane.net>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: RESET command seems pretty disjointed now
Next
From: Tom Lane
Date:
Subject: Re: Hacking on PostgreSQL via GIT