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
signature.asc
Description: OpenPGP digital signature
