Re: GIT and CVS

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 13 Oct 2011 23:59:28 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: Phil Muldoon <pmuldoon@redhat.com>, gdb@sourceware.org
> 
> On Thu, 13 Oct 2011 23:50:33 +0200, Joseph S. Myers wrote:
> > Even with local disk, git is much more I/O intensive.  I timed looking at 
> > logs from a glibc checkout on local disk:
> > 
> > $ time git log > /dev/null
> > 
> > real    0m18.324s
> > user    0m0.560s
> > sys     0m0.304s
> 
> $ time git log >/dev/null
> 
> real	0m0.374s
> user	0m0.330s
> sys	0m0.041s
> 
> You cannot count the first operation, before ./.git gets cached.  The first
> read is deficiency of kernel filesystem, pre-read and/or no SSD on your system.

These comparisons are meaningless.  Logs are meant to be read by
humans, so the number of seconds it takes to dump all the log entries
to the null device is not an interesting measure of any practical
importance.

More to the point: ChangeLog files can be generated from a VCS log
when a release is tarred.  They can also be generated when a developer
wants a convenient file to look at with usual tools.  So whether or
not to keep the ChangeLog files is not the issue.  The issue is how to
save the committers the need to compose 2 different logs, one for the
commit, the other for the ChangeLog.  This issue should be resolved by
the VCS front end in use, like Emacs or whatever people use.  When
such solutions exist, it is no longer an important issue whether to
keep ChangeLog's in the repo or generate them as needed.