Re: Emacs Bazaar repository

["Stephen J. Turnbull" <stephen@xemacs.org>]

Martin Pool writes:

 > This means that c and d were merged into this branch in revision b,
 > and were not previously present in the repository.  This layout gives
 > a good overview of the history, in our opinion a much better one than
 > what you get from tools that just print one path through the graph or
 > that print the revisions in arbitrary linear order.

OK, but is it worth a minute per execution when a minute will give me
a gitk view of the history?

 > To calculate which revisions are newly merged is currently done by
 > examining the whole graph.  We will do two things to speed it up:
 > faster loading of the graph from the repository, and caching some data
 > in the branch.

Well, as I pointed out in another post, in git the repo *is* the DAG.
No caches needed.

 > But possibly you don't want to know about merged in revisions, and
 > that can be done with bzr log --short or --line.  These should be able
 > to do much less work, just walking down through the revision to print.

I always want to know about the merged-in revisions.  It would never
occur to me to leave them out ... unless that was the only way to get
a sub-minute log, of course.  I'm really having trouble grasping what
kind of workflow this tool is intended for.

 > I want to point out that bzr branch locally, not in a single
 > repository, is doing more than just copying all the files - it is
 > filtering out and verifying the data relevant to the particular branch
 > you're copying.

But so does git fetch.  Of course, since the repo is the DAG, it
doesn't have to do any extra work.  If it finds the object, the DAG is
correct.  If it doesn't, the repo is corrupt.

I don't know the details of the git packed format, but since indicies
and content are in separate files, presumably the content packs could
be corrupt even though the DAG checks out.  But that will be caught
O(0) because git does a checksum for every transmission anyway.  I
assume that's true for bzr as well, of course.

 > >  # Command line typo on a local URL, bzr figures it out in 10s.
 > >  $ time bzr branch EMACS_22_BASE
 > >  bzr: ERROR: Not a branch: "/Users/steve/Software/Emacs/emacs-bzr/EMACS_22_BASE/".
 > >
 > >  real    0m10.183s       user    0m0.457s        sys     0m1.361s
 > 
 > Maybe you could send (perhaps just on the bzr list) a run of that with
 > "bzr --lsprof branch ...".  It may be that the low cpu usage is caused
 > by many things being pushed out of ram by building the emacs working
 > tree in the previous command.

That's really cold comfort.  My CPU and I/O bus are typically
multitasked.  Anyway, "user 0.457s + sys 1.361s" is over 10 times my
threshold of perception.  Presumably that's essentally all Python
startup overhead, since there was no branch to look at there.  That's
a real handicap against git, where "git-rev-list --topo" posts "user
0.060s + sys 0.124s" for >600 revs!

I ran "time bzr --lsprof branch EMACS_22_BASE" twice in succession.
The first was just over 10s wallclock again, the second down to just
under 6s.  URLs to profiles follow time output.

real    0m10.097s	user    0m1.109s	sys     0m1.828s
real    0m5.954s	user    0m0.768s	sys     0m1.201s

http://turnbull.sk.tsukuba.ac.jp/Tools/XEmacs/bzf.prof.0
http://turnbull.sk.tsukuba.ac.jp/Tools/XEmacs/bzf.prof.1