This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: A truely ugly hack...
- To: bkorb at cruzio dot com, gcc at gcc dot gnu dot org
- Subject: Re: A truely ugly hack...
- From: Mike Stump <mrs at windriver dot com>
- Date: Sat, 26 Aug 2000 09:59:11 -0700 (PDT)
- Cc: info-cvs at gnu dot org
> Date: Sat, 26 Aug 2000 09:31:37 -0700
> From: Bruce Korb <bkorb@cruzio.com>
> 3. The CVS commitinfo file works a little better, but has interesting
> problems, too. See below.
> So, of these, #3 has the most pleasing promise. But, there are problems..
I think you can solve the problem my doing the processing
asynchronously, jut spawn it off during a modification, and it'll test
to see if a new .[ch] file would be generated, and if so, it'll check
out the file, and modify it, then check it back in. If there is a
lock, have it sleep for 20 seconds (or so), and try again.
Would that work?
> 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.
No, please don't consider this.