| 1 |
Daniel Ostrow wrote: |
| 2 |
|
| 3 |
> Lance: |
| 4 |
> |
| 5 |
> I know this is a far cry from what you are proposing, and I understand |
| 6 |
> that the present CVS server cannot handle this sort of load but I |
| 7 |
> believe that this was the original intention at least...someone correct |
| 8 |
> me if I am wrong. |
| 9 |
|
| 10 |
One of the issues we had with direct cvs access is managing all of the |
| 11 |
AT accounts. If we're talking 50-100 ATs, that increases our user |
| 12 |
account management load by a lot considering we only have 300 developers |
| 13 |
right now. The other reason is of course with load on lark itself. We |
| 14 |
can only do so many concurrent cvs up's of the full tree and adding this |
| 15 |
many users concerns me alot with that aspect. |
| 16 |
|
| 17 |
As what kurt said in a followup to this email, If we can nail down that |
| 18 |
the primary need of the GLEP is quick access to changes, that will help |
| 19 |
us a lot in figuring out the logistics of the issue. |
| 20 |
|
| 21 |
I know pylon had talked about the newer cvs allowing for a virtually |
| 22 |
'live' update to another cvs box via a commit hook, but he's been rather |
| 23 |
busy lately and hasn't had a chance to work on that. I think that has |
| 24 |
the best hope down the road of resolving this GLEP. I would just like to |
| 25 |
keep the management of lark to the minimum if at all possible, so for |
| 26 |
now I would prefer a restricted rsync module or cvs box that gets |
| 27 |
updated every X minutes. |
| 28 |
|
| 29 |
Cheers- |
| 30 |
|
| 31 |
-- |
| 32 |
Lance Albertson <ramereth@g.o> |
| 33 |
Gentoo Infrastructure | Operations Manager |
| 34 |
|
| 35 |
--- |
| 36 |
GPG Public Key: <http://www.ramereth.net/lance.asc> |
| 37 |
Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742 |
| 38 |
|
| 39 |
ramereth/irc.freenode.net |
Archives