From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Emacs Bazaar repository Date: Sat, 15 Mar 2008 13:44:40 +0900 Message-ID: <87lk4ksiiv.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87skyvse7k.fsf@xmission.com> <87fxuvl0gi.fsf@offby1.atm01.sea.blarg.net> <87bq5j19ok.fsf@workhorse.earlhome> <873aqtuasq.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1205555798 13729 80.91.229.12 (15 Mar 2008 04:36:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Mar 2008 04:36:38 +0000 (UTC) Cc: Jonathan Lange , Jason Earl , emacs-devel@gnu.org To: "Martin Pool" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 15 05:37:04 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JaO8l-0005Ck-JY for ged-emacs-devel@m.gmane.org; Sat, 15 Mar 2008 05:37:04 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JaO8C-0003kp-1D for ged-emacs-devel@m.gmane.org; Sat, 15 Mar 2008 00:36:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JaO86-0003kV-6Y for emacs-devel@gnu.org; Sat, 15 Mar 2008 00:36:22 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JaO84-0003kE-8s for emacs-devel@gnu.org; Sat, 15 Mar 2008 00:36:20 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JaO83-0003k9-Tf for emacs-devel@gnu.org; Sat, 15 Mar 2008 00:36:19 -0400 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JaO83-00021h-GS for emacs-devel@gnu.org; Sat, 15 Mar 2008 00:36:19 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id E17DE1535A8; Sat, 15 Mar 2008 13:36:16 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id A42741A29EF; Sat, 15 Mar 2008 13:44:40 +0900 (JST) In-Reply-To: X-Mailer: VM 7.19 under 21.5 (beta28) "fuki" 2785829fe37c XEmacs Lucid X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:92655 Archived-At: 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