Re: The pain of committing ChangeLogs...

[Jeffrey A Law <law at redhat dot com>]

  In message <20010110234233.E21420@daikokuya.demon.co.uk>you write:
  > 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 :(
FWIW, I'm at the end of a 56k link too.  The only time I see things that
bad is when my 56k link is saturated because I'm downloading something
else across the link or someone stupidly sends me huge documents 
(like architecture manuals) via email :(


We do rotate the ChangeLog regularly and it appears that it's time again.
I'll take care of it tonight if nobody beats me to it.

  > I suspect a major cause of this is the ChangeLog file, and its
  > thousands of revisions causing considerable server load.
If you're working on the head of the trunk, then that shouldn't be
a problem (it is more of a problem if you're working on older
branches).

  > 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.
That would make it impossible to check out previous GCC releases.  So we
don't want to completely rotate the ChangeLog (ie we don't want to restart
at rev #1).

We do want to rotate the ChangeLog to make it smaller because that does
improve update & commit times.

jeff