This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

The pain of committing ChangeLogs...

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 :-)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]