Hi all,
I got a little time to think about the problem of generated
files in the CVS archive (viz. the "contrib" branch).
The files were removed from the main GCC hierarchy on the theory that
it is a pain to maintain them and most developers have the relevant
tools. The problem arises when there are developers that do not have
the relevant tools handy and there is no backup mechanism in place.
This gets us to an easily proved corollary: moving the generated files
into an obscure side hierarchy will be even less often maintained.
What to do? How about some kludgery? :-)
The goal would be to automatically commit updates to the generated
files whenever there are changes to their predecessor files.
There are several approaches:
1. A daemon process. This leaves a time delay between the commit
and the updated archive. Probably better than not having the
generated files available at all, but possibly inconvenient
for some.
2. The CVS config file does not work very well for this purpose
3. The CVS commitinfo file works a little better, but has interesting
problems, too. See below.
4. Try to maintain it all by hand. It will get out-of-date, but
developers ought to have the tools anyway. [[gag! ;-( ]]
5. Don't have the tools? Tough bounce. (current scheme)
So, of these, #3 has the most pleasing promise. But, there are problems..
The ugliest is that in order to generate the updated file, you have to
have access to the predecessor files that are not being checked in.
(Those are are available.) In order to get access, you have to be
able to: cvs -d xxx get -r dir-path/mumble -- Oops. You cannot because
'dir-path' is locked during the processing of the commitinfo command
by a parent processes. Isn't *that* special? That renders #3 (and
#2) completely impossible. Unless you implement a Truely Ugly Hack.
The Truely Ugly Hack:
Determine if the "dir-path/.#cvs?*" refers to an ancestor process and,
if so, move the .#cvs* files & dirs aside, do what you gotta do, and
move them back. (Recursively, of course :-) Yummy.
I have played with a prototype of this enough to know it is a computable
problem. (I actually got it mostly working.) Before actually finishing,
though, I wanted a little feedback. Finishing it would be too much work
to just throw away.
Cheers,
Bruce
P.S. I cc-ed info-cvs so those folks can suggest a Better Method :-)
