From: | Thomas Lockhart <lockhart(at)fourpalms(dot)org> |
---|---|
To: | Michael Meskes <meskes(at)postgresql(dot)org> |
Cc: | PostgreSQL Hacker <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ecpg and bison again |
Date: | 2002-06-19 14:19:15 |
Message-ID: | 3D1092E3.EEC65872@fourpalms.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > Perhaps there is some usefulness in adding 'preproc-inprogress.y' to
> > the repository and those interested in ecpg changes and who have the
> > relevant bison installed can manually copy it to 'preproc.y'?
> Is this something we can agree on? I'm willing to even add
> preproc-inprogress.c, but I'm not sure if this generates the same
> problems as with preproc.c.
Actually, this situation is *exactly* what CVS is made to help with.
Make a branch on the src/interfaces/ecpg directory (call it, say,
"ecpg_big_bison", or whatever you want) and then you can commit on that
branch, others can see the branch if they want, and you don't have to
carry along code without committing it.
I can help make the branch (or suggest the commands to do so) if that
would be helpful.
Later, you can merge the branch down to the main trunk. And in the
meantime, you can merge *up* from the main trunk if there are fixes you
want to apply to both versions, again with a one line cvs command.
So, let's use cvs to do this rather than having to create a separate
temporary file. I've done this very successfully on other large projects
so am confident that it will work well for us.
- Thomas
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-06-19 14:25:00 | Re: SetQuerySnapshot, once again |
Previous Message | Tony Griffiths(RA) | 2002-06-19 14:18:57 | Re: Missing library files?? |