This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
The pain of committing ChangeLogs...
- To: gcc at gcc dot gnu dot org
- Subject: The pain of committing ChangeLogs...
- From: Neil Booth <neil at daikokuya dot demon dot co dot uk>
- Date: Wed, 10 Jan 2001 23:42:34 +0000
- Cc: Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>
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.
Could we agree to maybe rotate the ChangeLog file more frequently, say
every 2 months max, and when we rotate, to *completely flush* the
server's memory of the ChangeLog file by cvs remove (or whatever it
requires - I'm not an expert on CVS innards) so we start from revision
1 again.
To avoid accumulating lots of smaller ChangeLog files, we can
concatenate these more rapidly rotated ChangeLogs when rotating, but
just letting an enormous ChangeLog build up from thousands of
incremental bits seems to cause the server some pain, and quite a
check-in delay.
By contrast, a check-in in the wwwdocs directory is
near-instantaneous, even for me. That has no ChangeLog :-)
Neil.