Re: Abolishing ChangeLog files

[Dmitry Gutov <dgutov@yandex.ru>]

On 29.03.2013 10:10, Eli Zaretskii wrote:
>> Date: Fri, 29 Mar 2013 08:45:44 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> Btw: bzr logs all of its times in .bzr.log, so you don't need any
> additional programs to time it.  (I wish git had such a comprehensive
> logging facility, it proved invaluable for me quite a few times in the
> past.)
>

If you mean that it writes to ~/bazaar/.bzr.log, then it doesn't, here. 
The file exists, but all the entries there are from September 1st last 
year. Not important, just an aside.

 > Attached below.

Thank you. It inspired me to run the same non-interactive tests you did, 
and indeed the full 'git log lisp\progmodes\ruby-mode.el > NUL' 
invocation is non-instantaneous every time, and it's on the same order 
of magnitude as 'bzr log', although the latter takes twice as long:

emacs-git-savannah>timep git log lisp\progmodes\ruby-mode.el > NUL

real    00h00m04.652s
user    00h00m00.000s
sys     00h00m00.015s

emacs-bzr\trunk>timep bzr log lisp\progmodes\ruby-mode.el > NUL

real    00h00m08.269s
user    00h00m07.878s
sys     00h00m00.280s

But! Git starts streaming output just as soon as it can, hence my 
earlier impression that the command is instantaneous. If you redirect 
its output to 'less' (like I did in the command I sent in one of the 
previous messages), you'll see that the viewer opens near instantly, and 
allows you to view the latest commits while the VCS fetches the older 
data. Same thing happens when a user calls `vc-print-log' in Emacs, and 
it makes all the difference.

Here's a more striking example. Show the last 40 commits:

emacs-git-savannah>timep git log -40 lisp\progmodes\ruby-mode.el > NUL

real    00h00m00.226s
user    00h00m00.015s
sys     00h00m00.000s

emacs-bzr\trunk>timep bzr log -l 40 lisp\progmodes\ruby-mode.el > NUL

real    00h00m08.273s
user    00h00m07.878s
sys     00h00m00.265s

Git is finally fast, but Bazaar is as slow as when it retrieves the full 
history.

 >> I don't see this kind of problem with Git, but maybe I just haven't
 >> tried it with a repository hosted on the same server as Bazaar one.

 > I did, just now: (...)

I tried it, too, and here Git wins hands-down.

Here's how long it takes to update both when they are already up-to-date 
(staging a situation when they're the same number of revisions 
out-of-date is harder):

emacs-git-savannah>timep git pull
Already up-to-date.

real    00h00m02.139s
user    00h00m00.000s
sys     00h00m00.031s

emacs-bzr\trunk>timep bzr update
Дерево в актуальной ревизии 112180 ветви 
bzr+ssh://dgutov@bzr.savannah.gnu.org/emacs/trunk


real    00h00m09.963s
user    00h00m00.343s
sys     00h00m00.202s


Before that, I updated this Bazaar clone from a several-days-old 
revision, and it took 4 minutes. I don't have a similar result for Git 
to compare, but considering it cloned the whole history in 30 minutes 
(same as on your machine), it will likely be faster.

emacs-bzr\trunk>timep bzr update
+N  lisp/eshell/em-tramp.el
  M  ChangeLog
  M  admin/CPP-DEFINES
  M  autogen/config.in
  M  autogen/configure
  M  configure.ac
  M  doc/lispref/ChangeLog
  M  doc/lispref/compile.texi
  M  doc/misc/eshell.texi
  M  etc/NEWS
...
...
...
  M  src/xselect.c
  M  src/xsmfns.c
  M  src/xterm.c
All changes applied successfully.
Обновлено до ревизии 112180 ветви 
bzr+ssh://dgutov@bzr.savannah.gnu.org/emacs/trunk

real    00h04m11.939s
user    00h00m06.520s
sys     00h00m01.466s