Обсуждение: ecpg and bison again
How about we add the preproc.c file generated by bison 1.49 to cvs? Could that create problems elsewhere? The version that is part of the source tree now is generated on the server, isn't it? Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes <meskes@postgresql.org> writes:
> How about we add the preproc.c file generated by bison 1.49 to cvs?
> Could that create problems elsewhere?
Yes. It's a bad idea to put derived files in CVS. For one thing,
CVS will not guarantee that their timestamps are right compared to
the master file.
regards, tom lane
On Tue, Jun 18, 2002 at 04:41:57PM -0400, Tom Lane wrote: > Michael Meskes <meskes@postgresql.org> writes: > > How about we add the preproc.c file generated by bison 1.49 to cvs? > > Could that create problems elsewhere? > > Yes. It's a bad idea to put derived files in CVS. For one thing, > CVS will not guarantee that their timestamps are right compared to > the master file. Actually I thought about changing the makefile as well, so preproc.c does not look like a derived file anymore. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes <meskes@postgresql.org> writes:
> On Tue, Jun 18, 2002 at 04:41:57PM -0400, Tom Lane wrote:
>> Michael Meskes <meskes@postgresql.org> writes:
> How about we add the preproc.c file generated by bison 1.49 to cvs?
> Could that create problems elsewhere?
>>
>> Yes. It's a bad idea to put derived files in CVS. For one thing,
>> CVS will not guarantee that their timestamps are right compared to
>> the master file.
> Actually I thought about changing the makefile as well, so preproc.c
> does not look like a derived file anymore.
That cure would be FAR worse than the disease. Leave it be.
The time for panic will be in August, if we are ready to make a beta
release and there's still no bison release. In the meantime I really
don't see why you can't keep updating your copy of preproc.y and
just not commit it...
regards, tom lane
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'? Otherwise the ecpg changes are not going to get any testing apart from Michael's... Regards, Lee Kindness. Tom Lane writes:> Michael Meskes <meskes@postgresql.org> writes:> > Actually I thought about changing the makefile as well,so preproc.c> > does not look like a derived file anymore.> That cure would be FAR worse than the disease. Leave itbe.
On Wed, Jun 19, 2002 at 09:06:31AM -0400, Tom Lane wrote: > release and there's still no bison release. In the meantime I really > don't see why you can't keep updating your copy of preproc.y and > just not commit it... I can for sure, but no one else can use it. And I have to be very careful with patches someone else commits. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
On Wed, Jun 19, 2002 at 02:22:08PM +0100, Lee Kindness wrote: > 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. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes <meskes@postgresql.org> writes:
> On Wed, Jun 19, 2002 at 02:22:08PM +0100, Lee Kindness wrote:
>> 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.
Seems to me that it would.
I agree it's not pleasant to be blocked like this. Is there any way we
can persuade the bison guys to be a little more urgent about releasing a
fix? (If 1.49 is just an internal beta version, maybe a back-patch to
their last released version?)
Another possibility is to temporarily disable ecpg from being built by
default (eg, just remove it from src/interfaces/Makefile) and then go
ahead and commit your changes. Then, anyone wanting to test it would
have to (a) have a suitable bison installed and (b) manually go into
interfaces/ecpg and say "make all install". I can't say that I like
this idea, but it seems better than putting derived files into CVS.
regards, tom lane
PS: BTW, are any of the bison people at Red Hat? Maybe I could apply
a little internal pressure...
> > 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
Tom Lane wrote: > Michael Meskes <meskes@postgresql.org> writes: > > On Tue, Jun 18, 2002 at 04:41:57PM -0400, Tom Lane wrote: > >> Michael Meskes <meskes@postgresql.org> writes: > > How about we add the preproc.c file generated by bison 1.49 to cvs? > > Could that create problems elsewhere? > >> > >> Yes. It's a bad idea to put derived files in CVS. For one thing, > >> CVS will not guarantee that their timestamps are right compared to > >> the master file. > > > Actually I thought about changing the makefile as well, so preproc.c > > does not look like a derived file anymore. > > That cure would be FAR worse than the disease. Leave it be. > > The time for panic will be in August, if we are ready to make a beta > release and there's still no bison release. In the meantime I really > don't see why you can't keep updating your copy of preproc.y and > just not commit it... I think it is fine to add a bison C file to CVS until we get bison updated, and Michael can control that. We can always remove it later. Is the problem that they C file will not have the proper timestamp? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Thomas Lockhart <lockhart@fourpalms.org> writes:
> 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.
Seems like a plan...
regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Is the problem that they C file will not have the proper timestamp?
Exactly. Don't you remember all the troubles we had back when we
did have the derived files in CVS? I don't want to have to deal
with that again, even for a short while.
regards, tom lane
> > 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.
> Seems like a plan...
Michael, is this acceptable to you? If you use remote cvs, then you
would update *only* the src/interfaces/ecpg directory on the branch tag,
and from then on your local copy (and your interactions with cvs) will
be on that branch. Other options to cvs commands can force your local
copy back to the main trunk, can pull main trunk updates up to the
branch, etc etc. And at the end when you don't need it anymore we can
even get rid of the tagged branch altogether.
I'm happy setting up the branch if that would be helpful. Let me know if
this is the way you want to proceed, and if so what you would like the
branch to be called.
- Thomas
On Wed, Jun 19, 2002 at 10:14:32AM -0400, Tom Lane wrote: > I agree it's not pleasant to be blocked like this. Is there any way we > can persuade the bison guys to be a little more urgent about releasing a > fix? (If 1.49 is just an internal beta version, maybe a back-patch to > their last released version?) I had the feeling they rewrote some major parts. You cannot back-patch that. But then I may err on this. > Another possibility is to temporarily disable ecpg from being built by > default (eg, just remove it from src/interfaces/Makefile) and then go > ahead and commit your changes. Then, anyone wanting to test it would > have to (a) have a suitable bison installed and (b) manually go into > interfaces/ecpg and say "make all install". I can't say that I like > this idea, but it seems better than putting derived files into CVS. That would be possible too. > PS: BTW, are any of the bison people at Red Hat? Maybe I could apply > a little internal pressure... No idea, sorry. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
On Wed, Jun 19, 2002 at 06:23:24PM -0700, Thomas Lockhart wrote: > Michael, is this acceptable to you? If you use remote cvs, then you Yes, it is. > I'm happy setting up the branch if that would be helpful. Let me know if > this is the way you want to proceed, and if so what you would like the That would be nice. I do not really knwo cvs myself. > branch to be called. No idea. "new-bison" maybe? Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
> > I'm happy setting up the branch if that would be helpful. Let me know if
> > this is the way you want to proceed, and if so what you would like the
> That would be nice. I do not really knwo cvs myself.
Done. And here is how you would use it...
> > branch to be called.
> No idea. "new-bison" maybe?
OK, the tag name is "ecpg_new_bison" (note the underscores; dashes are
not allowed afaicr).
I created the branch *only* on src/interfaces/ecpg. To get ready to work
on the branch, you will want to update your entire tree:
cvs update -PdA pgsql
If you have uncommitted changes to code cvs will respect that and
preserve the changes, but you may want to make a tarball just in case ;)
Then, update *only* the ecpg source directory to the branch:
cd pgsql/src/interfaces
cvs update -r ecpg_big_bison ecpg
At that point, *all* cvs files in your ecpg directory will be living on
the branch. If you make changes and commit them, the changes will only
be visible on the branch. The branch tag is "sticky", so *unless* you
explicitly change the tag or branch by, say, an unfortunate "update -A"
or "update -rHEAD" then all files and any new files will stay on the
branch.
Since the tag is only on the src/interfaces/ecpg directory, if you
accidentally try updating other directories to that tag the files may
"vanish", since they do not have that tag. Update those directories back
to the head and the files will reappear.
You can easily work on both the HEAD and ecpg_big_bison by renaming your
already-branched ecpg directory to, say, ecpg.big, then doing
cd pgsql/src/interfaces
cvs update -PdA ecpg
which will recover files from the tip of the cvs tree. You would then
have two directories, ecpg/ and ecpg.big/, and the sticky tags in
ecpg.big/ will be respected by CVS and will still refer to the correct
branch of ecpg/ within the CVS repository.
If you commit changes to the tip which you want to pull up to the
branch, use
cd pgsql/src/interfaces
# name may be ecpg/ if you have a completely separate tree
cvs update -j HEAD ecpg.big
which will merge changes from HEAD (the cvs tip) into your source
directory. You would still need to commit them to have them in the
repository:
cd pgsql/src/interfaces
cvs commit ecpg.big
When it comes time, you will want to merge your branch back down to the
main tree. You can do this as was done above for the other direction:
cd pgsql/src/interfaces
cvs update -j ecpg_big_bison ecpg
where the ecpg directory is, as described above, already on the cvs tip.
Let me know if you have any questions!
- Thomas
A couple of notes:
...
> Then, update *only* the ecpg source directory to the branch:
> cd pgsql/src/interfaces
> cvs update -r ecpg_big_bison ecpg
cvs will respect any changes you have made to the sources in your
directory and the changes will be preserved in the move to the branch.
Here is what the update looks like on my machine:
myst$ cvs update -r ecpg_big_bison ecpg
cvs update: Updating ecpg
cvs update: Updating ecpg/include
cvs update: Updating ecpg/lib
? ecpg/lib/libecpg.so.3.2.0
? ecpg/lib/libecpg.so.3.3.0
? ecpg/lib/libecpg.so.3.4.0
cvs update: Updating ecpg/preproc
? ecpg/preproc/ecpg
cvs update: Updating ecpg/test
If you want to check on the branch status of a particular file use the
"status" command. For example, checking on ecpg/Makefile looks like:
myst$ cvs status ecpg/Makefile
===================================================================
File: Makefile Status: Up-to-date
Working revision: 1.14 Mon Feb 4 15:37:13 2002 Repository revision: 1.14
/home/thomas/cvs/repository/pgsql/src/interfaces/ecpg/Makefile,v Sticky Tag: ecpg_big_bison (branch: 1.14.4)
StickyDate: (none) Sticky Options: (none)
(I'm using cvsup so the repository path is local to my machine in this
example.)
- Thomas
> I get
> cvs [server aborted]: cannot write /cvsroot/CVSROOT/val-tags: Permission denied
> This seems to be a server message.
I see the same thing when trying to update a tree to this branch using
local cvs on mcvsup.postgresql.org. The file is owned by scrappy and has
no group write permissions.
I use CVSup, and looking at the permissions on my local CVS repository
(which does allow me to work with the branch) that file is group (and
world!?) writable:
29501576 -rw-rw-rw- 1 thomas thomas 33 Jun 23 07:37
val-tags
And looking at another CVS repository with "known good" behavior I see
that the file is group-writable.
scrappy, can you adjust the permissions on /cvsroot/CVSROOT to allow
group writes, and adjust the permissions on /cvsroot/CVSROOT/val-tags to
allow group writes? Perhaps it is just the permissions on the directory
which are the problem, but it seems that no branch operations are
currently allowed :(
- Thomas
On Sun, Jun 23, 2002 at 06:47:46PM -0700, Thomas Lockhart wrote: > > I get > > cvs [server aborted]: cannot write /cvsroot/CVSROOT/val-tags: Permission denied > > This seems to be a server message. > > I see the same thing when trying to update a tree to this branch using > local cvs on mcvsup.postgresql.org. The file is owned by scrappy and has > no group write permissions. It seems the file is still not writable. Or is there a mistake on my side? Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!