CVS conflict avoidance

[Robert Lipe]

[ No, not the sort of conflict that's filling the gcc list. ] 


I've danced around this for a while, but a discussion with Jeff made
me start thinking about it harder.

We have several files in EGCS that are generated from other files in 
EGCS.  These include pairs like configure.in and configure and *-parse.y
and *-parse.c.

If you are using remote CVS and don't have exactly the same version of
autoconf or bison or byacc or whatever, the timestamp thing can sneak up
on you.  For example, if we do an update and CVS ships is both parse.c
and parse.y, CVS guarantees that they'll arrive alphabetically (sigh).
So *this time*, make will regenerate parse.c from parse.y.  Now, say we
have a slightly different bison than whoever is doing the master version
(this is more apparant in autoconf than in bison, but humor me) Now, the
next time we do an update, if it sees a reason to update only parse.c
(no, I don't understand why but it does happen) we're almost guaranteed
to have a conflict to resolve.  Of course, the easiest way to resolve
this conflict is to 'rm parse.c ; cvs update parse.c'.   Unfortunately,
I typically don't notice the conflict until the build that I just left
to run overnight unattended fails after about 10 minutes. 

This seems to be become a problem only when one half or the other of the
pair isn't updated and the other is and the generated file is generated
locally by slightly different tools than the tools used to generate the
one that's in the repository.  I could have the exact circumstances
wrong, but the punchline is that conflicts in configure and *-parse.c
files seem common.

I've now experimented with .cvsignore to try to make it ignore only the
generated files or only the source files, but once files are explictly
added to the repository (i.e. they appear in CVS/Entries) the .cvsignore
doesn't seem to matter.

I've thought about adding a top-level makefile target that touches
either the set of source files or the set of generated files depending
on whether you had m4, autoconf, bison, etc. or you wanted to just be in
"snapshot mode" and expect everything ready to run.  This seems pretty
kludgey.

Can anyone think of a better way to handle this?

-- 
Robert Lipe       http://www.dgii.com/people/robertl       robertl@dgii.com