Re: Commit practices

[Dan Nicolaescu <dann@ics.uci.edu>]

Richard Stallman <rms@gnu.org> writes:

  > The reason I have asked people not to commit multiple files
  > is that they bloat the log entries of each file, making them
  > essentially unusable.

Your opposition to multiple file commits seems to be based on the
assertion that this "bloats the log entries of each file, making them
essentially _unusable_".  

It's hard to find this assertion valid. 

In the worst case we would end with the log for each file containing the
whole ChangeLog (and that is obviously absurd).
Even in that absurd case isearch is quite efficient.
Now that isearch can switch to a different file ChangeLog file,
starting a C-s from lisp/ChangeLog and searching for 1985-05-11 (the
last entry in lisp/ChangeLog.1) takes no observable time and that is on
the slowest machine that I tried: a 500MHz P3.

GCC has been doing multiple file commits for at least 10 years. And the
logs are quite readable, you can check for yourself.

On the other hand doing only single file commits has a high cost in
developer time. Sometime CVS is very slow, waiting for each commit to go
through takes a while. 
The most efficient tool we have now for committing to CVS, PCL-CVS works
very well selecting a group of files for a logical commit, writing a
ChangeLog for them and committing them in one shot.  This process
is much less labor intensive than committing files one by one.  And
developer time is the most precious resource that we have.

  >     I did it this way for a reason.  Someday we are going to want to
  >     migrate the CVS tree to a VCS that has real changesets.  We're almost
  >     certainly going to do it with a tool functionally like cvs2svn that
  >     tries to reconstruct commit groups using date, the content of the
  >     comments, and possibly this Commit-ID thing I see in the CVS logs. It
  >     will be helpful, when we do that, if there as many similarities across
  >     related commits as possible for the migration tool to grab onto.
  > 
  > In effect, the suggestion here is that we abandon the idea
  > of useful readable info associated by the VCS with each file.
  > 
  > That would mean that the ChangeLog file is the only place
  > for such info.

There's no reason to go that far. As shown above allowing multiple file
commits is not a problem.