This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gcc development schedule [Re: sharing libcpp between GDB andGCC]
- From: Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>
- To: overseers at gcc dot gnu dot org
- Cc: Zack Weinberg <zack at codesourcery dot com>, "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>, <gcc at gcc dot gnu dot org>, <gdb at sources dot redhat dot com>, <jimb at redhat dot com>, <rth at redhat dot com>
- Date: Thu, 28 Mar 2002 10:22:49 +0100 (CET)
- Subject: Re: gcc development schedule [Re: sharing libcpp between GDB andGCC]
[ moved to overseers ]
On Wed, 27 Mar 2002, Zack Weinberg wrote:
>>> (E.g. it takes about 10x longer to do "cvs update" on the 3.0
>>> branch than the trunk.)
>> Yeah, what's up with that? (I thought it was just me.)
Same here.
On the gcc-3.1 branch, I'm approaching the situation where cvs update
takes longer than bootstrapping the compiler (with C and C++ frontends).
> The way RCS stores branches makes the cost of calculating diffs from a
> branch tip proportional to the number of versions on the branch *and*
> the distance between the branchpoint and top-of-trunk. I imagine
> update has to do diffs for some reason.
>
> That's the problem I know about; there may be others.
Overseers, is there anything we can do?
I noticed that we have more anoncvs processes running than authenticated
users; is there any way we could find out which CVS modules these
anonymous users currently access? (If it's gcc, we could see whether
we can simply disable anoncvs access to the gcc module.)
Gerald
--
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/