Re: Hacking on PostgreSQL via GIT

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Aidan Van Dyk <aidan(at)highrise(dot)ca>
Cc: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Hacking on PostgreSQL via GIT
Date: 2007-04-17 00:57:02
Message-ID: 12781.1176771422@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Aidan Van Dyk <aidan(at)highrise(dot)ca> writes:
> * Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-04-17 01:11:22 Re: Hacking on PostgreSQL via GIT
Previous Message Tom Lane 2007-04-17 00:24:41 Re: RESET command seems pretty disjointed now