Re: Emacs Bazaar repository

[Stephen J. Turnbull]

John Arbash Meinel writes:

 > (I believe 'git log' defaults to showing the log based on a local sort
 > by date. Neither one tries to figure out that A1 and A2 were merged into
 > tip, which is another step that 'bzr log' does.)

YAGNI most of the time, though.  John, I know where you're coming
from, but it looks like you're throwing up red herrings and making
excuses.  There's no question that git is good enough for Emacs on a
day-to-day basis.  bzr's performance problems make me wonder if it is.

It would be interesting to see a "time git rev-list --topo-order"
(which does the same thing as "bzr log" AFAICS) on the relevant repo.
Here are two timings on my most complicated XEmacs git repo (but it
only has 601 changesets, including 40 branches and 38 merges):

chibi:git-staging steve$ time git-rev-list --topo-order HEAD
[[ output omitted ]]

real    0m1.131s        user    0m0.060s        sys     0m0.124s

chibi:git-staging steve$ time git-rev-list --topo-order HEAD | wc
     601     601   24641

real    0m0.423s        user    0m0.060s        sys     0m0.130s

So let's scale that up to 90,000 commits assuming O(n) (which may not
be implausible for a topological sort on a DAG): user time of 9s.

I conclude that git chose the right representation for a DAG of
changesets right off the bat.  It is <effect sound="drum roll" />
a DAG of changesets.

AFAICT, both bazaar and Mercurial said, "whoa, that's going to be
inefficient in some operations", and immediately chose array
representations with some kind of temporal index (temporal because
they want all inserts in the database to be file appends for ACID and
efficiency).  Linus said "Listen to Tony", and he proved right when
the "git pack" format was introduced.

Original Arch and Darcs are "set of changeset"-oriented, so they can't
be compared to the DAG-oriented ones on this dimension; they can do
things directly that git, bzr, and hg can't (although I wouldn't put
it past Linus and/or other gitfans to implement efficient indirect
ways to accomplish them).

This is a consequence of what I posted a couple of months ago.  git is
a Lisp specialized to manipulating revision DAGs and accessing the
underlying revisions.

None of this is intended to specifically advocate git for the Emacs
repo.  Mercurial is probably good enough (an estimate after using it
with XEmacs, a comparable codebase but only about 500 revisions, since
early December).  bzr is likely good enough too.  Both have UI
advantages over git at the moment, and bzr log is definitely the best
(if you ignore how slow it is), but why bother with "bzr log" when
"gitk" is almost certainly equally fast (and much faster to update
than bzr log is to run again)?

OTOH, many Emacs developers won't run any vcs by hand, they'll use
vc.el or pcl-<vcs>.el (which doesn't exist for vcs in (git hg bzr)
AFAIK, but if Emacs chooses one, I bet it's a matter of days).  In
that case it's important that *all* vc and pcl operations be
acceptably efficient.