The pain of committing ChangeLogs...

[Geoff Keating]

Neil Booth <neil@daikokuya.demon.co.uk> writes:

> I'm on a sucky 56K link, and increasingly I'm getting the following
> sequence of events:-
> 
> 1) cvs update ChangeLog [3 minute+ server-end delay]
> 2) cvs commit ChangeLog blah [3-minute+ server-end delay]
> 3) cvs server: ChangeLog not up-to-date coz some $%!@#^ has committed
>    something on their super-fast, or local, connection [another 2 minute
>    delay while conflict downloaded] in the meantime
> 4) resolve ChangeLog conflict
> 5) go back to 1 :(
> 
> I looped about 4 times this morning over a 45 minute period, just
> trying to commit a couple of files.  Am I the only one?
> 
> I suspect a major cause of this is the ChangeLog file, and its
> thousands of revisions causing considerable server load.

I don't think so.  If that was true, it would take a long time to
commit ChangeLogs even from a close network, and it doesn't.

More likely, you're seeing that it takes substantial time to send a
half-megabyte or so ChangeLog file down a 56k pipe.

(Alternatively, it could be that something else on sourceware is
overloading it.  The presently running processes are:

USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
qmailr   20222  0.1  0.0  1136  392 ?        D    Jan06  10:00 qmail-rspawn
listarch 23814 58.2  0.6  6220 5088 ?        R    15:59   0:02 perl /usr/local/b
geoffk   23844  0.0  0.1  2520  896 pts/0    R    15:59   0:00 ps arux
qmaild   23846  0.0  0.0  1072  300 ?        R    15:59   0:00 qmail-smtpd
qmailr   23847  0.0  0.0  1136  392 ?        R    15:59   0:00 qmail-rspawn

so it may be that the mailing list management is getting expensive.)

-- 
- Geoffrey Keating <geoffk@geoffk.org>