On 23/11/05, Lance Albertson <[EMAIL PROTECTED]> wrote: > Daniel Ostrow wrote: > > > Lance: > > > > I know this is a far cry from what you are proposing, and I understand > > that the present CVS server cannot handle this sort of load but I > > believe that this was the original intention at least...someone correct > > me if I am wrong. > > One of the issues we had with direct cvs access is managing all of the > AT accounts. If we're talking 50-100 ATs, that increases our user > account management load by a lot considering we only have 300 developers > right now. The other reason is of course with load on lark itself. We > can only do so many concurrent cvs up's of the full tree and adding this > many users concerns me alot with that aspect. > > As what kurt said in a followup to this email, If we can nail down that > the primary need of the GLEP is quick access to changes, that will help > us a lot in figuring out the logistics of the issue. > > I know pylon had talked about the newer cvs allowing for a virtually > 'live' update to another cvs box via a commit hook, but he's been rather > busy lately and hasn't had a chance to work on that. I think that has > the best hope down the road of resolving this GLEP. I would just like to > keep the management of lark to the minimum if at all possible, so for > now I would prefer a restricted rsync module or cvs box that gets > updated every X minutes. > > Cheers- > > -- > Lance Albertson <[EMAIL PROTECTED]> > Gentoo Infrastructure | Operations Manager > > --- > GPG Public Key: <http://www.ramereth.net/lance.asc> > Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742 > > ramereth/irc.freenode.net > > What about finding out how many ATs are going to be using it at the start and limiting the amount of ATs with access to <40-50 until either a new way for access has been decided on or new equipment has been brought it. Currently I wouldn't need it because I am without amd64 equipment until after equipment.
George -- gentoo-dev@gentoo.org mailing list
