From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: John Arbash Meinel Newsgroups: gmane.comp.version-control.bazaar-ng.general,gmane.emacs.devel Subject: Re: Emacs Bazaar repository Date: Fri, 14 Mar 2008 08:23:29 +0000 Message-ID: <47DA3601.3040507@arbash-meinel.com> References: <87skyvse7k.fsf@xmission.com> <86ejae96t4.fsf@lola.quinscape.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1205501077 1349 80.91.229.12 (14 Mar 2008 13:24:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Mar 2008 13:24:37 +0000 (UTC) Cc: schwab@suse.de, dak@gnu.org, emacs-devel@gnu.org, Matthieu Moy , bazaar@lists.canonical.com To: Eli Zaretskii Original-X-From: bazaar-bounces@lists.canonical.com Fri Mar 14 14:25:04 2008 Return-path: Envelope-to: gcvbg-bazaar-ng@m.gmane.org Original-Received: from chlorine.canonical.com ([91.189.94.204]) by lo.gmane.org with esmtp (Exim 4.50) id 1Ja9u7-00066U-2K for gcvbg-bazaar-ng@m.gmane.org; Fri, 14 Mar 2008 14:24:59 +0100 Original-Received: from localhost ([127.0.0.1] helo=chlorine.canonical.com) by chlorine.canonical.com with esmtp (Exim 4.60) (envelope-from ) id 1Ja9tX-0006t1-Ui; Fri, 14 Mar 2008 13:24:23 +0000 Original-Received: from flpi102.sbcis.sbc.com ([207.115.20.71] helo=flpi102.prodigy.net) by chlorine.canonical.com with esmtp (Exim 4.60) (envelope-from ) id 1Ja9tT-0006s6-55 for bazaar@lists.canonical.com; Fri, 14 Mar 2008 13:24:19 +0000 X-ORBL: [75.51.62.134] Original-Received: from juju.arbash-meinel.com (adsl-75-51-62-134.dsl.chcgil.sbcglobal.net [75.51.62.134]) by flpi102.prodigy.net (8.13.8 out.dk.spool/8.13.8) with ESMTP id m2EDO3iI001720; Fri, 14 Mar 2008 06:24:04 -0700 Original-Received: by juju.arbash-meinel.com (Postfix, from userid 505) id CA36556088; Fri, 14 Mar 2008 07:24:56 -0600 (CST) X-Spam-Score: -103.9 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on juju.arbash-meinel.com X-Spam-Level: X-Spam-Status: No, score=-103.9 required=4.5 tests=ALL_TRUSTED,BAYES_00, DATE_IN_PAST_03_06,USER_IN_WHITELIST autolearn=ham version=3.1.7 Original-Received: from [192.168.2.14] (samus.arbash-meinel.com [192.168.2.14]) by juju.arbash-meinel.com (Postfix) with ESMTP id 8721856025; Fri, 14 Mar 2008 07:24:45 -0600 (CST) User-Agent: Thunderbird 2.0.0.12 (X11/20080227) In-Reply-To: X-Enigmail-Version: 0.95.0 X-BeenThere: bazaar@lists.canonical.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: bazaar discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bazaar-bounces@lists.canonical.com Errors-To: bazaar-bounces@lists.canonical.com Xref: news.gmane.org gmane.comp.version-control.bazaar-ng.general:38563 gmane.emacs.devel:92545 Archived-At: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eli Zaretskii wrote: >> From: Matthieu Moy >> Date: Fri, 14 Mar 2008 10:58:13 +0100 >> Cc: Andreas Schwab , emacs-devel@gnu.org, >> bazaar@lists.canonical.com >> >>> Andreas Schwab writes: >>> >>>> My first impression is that bzr is slow, so slow that it is completely >>>> unusable. How can it come that a simple bzr log takes more than a >>>> minute to even start? Even cvs log is instantaneous in comparison, >>>> although it has to request the log from the server. >> [...] >> As opposed to that, bzr has to get a global view of history at least >> to get the revision numbers (there was some plans caching this >> information, I don't know what's the status). >> >> That said, the time for bzr log to start should clearly not be _that_ >> long. > > Incidentally, why are we concentrating on "bzr log"? is that a > frequent operation? With CVS, I find myself doing "cvs log" only once > in a few months, when I'm looking for a change corresponding to some > ChangeLog entry. > > Aren't "push" and "pull" much more important, as far as speed is > concerned, for everyday work? Also the equivalent of "cvs diff", I > think. Those are the ops I use much more frequently than "log" and > "annotate". I think it is because 'bzr log' is surprisingly slow when compared to other systems, while the other commands are not. The biggest reason 'bzr log' is slow is because we spend some time analyzing the ancestry to give a "pretty" view, while git/hg do not. Specifically, when you do "bzr log" we traverse the ancestry to figure out when revisions were merged, etc. I believe plain "git log" just starts outputting the revisions as it encounters them, and "hg log" also outputs them as they are stored. In the case of "hg" that means that the order of operations you did to create the branch will change the order you see them displayed. So if you and someone else do 2 commits and then you merge them, and they pull you. At that point "hg log" gives different results, even though both branches are "the same". For example: hg init A cd A echo foo > foo hg add hg commit -m 'init' cd .. hg clone A B cd A echo "A1" >> foo hg commit -m "A1" echo "A2" >> foo hg commit -m "A2" cd ../B echo "B1" > bar hg add hg commit -m "B1" echo "B2" >> bar hg commit -m "B2" hg pull ../A hg merge hg commit -m "Merged" cd ../A hg pull -u ../B At that point doing: cd A hg log gives me: (paraphrased for clarity) changeset: 5:04157da570b3 summary: Merged changeset: 4:e44ea38fbbb9 summary: B2 changeset: 3:d2df37f438ac summary: B1 changeset: 2:111f2448422b summary: A2 changeset: 1:3a8ecee8c0bf summary: A1 changeset: 0:5a118c651080 summary: init versus cd B hg log changeset: 5:04157da570b3 summary: Merged changeset: 4:111f2448422b summary: A2 changeset: 3:3a8ecee8c0bf summary: A1 changeset: 2:e44ea38fbbb9 summary: B2 changeset: 1:d2df37f438ac summary: B1 changeset: 0:5a118c651080 summary: init The other thing is that these numbers are going to be permanently different for the two branches. Which means that you can't refer to "revno 4 in branch A". Because someone with an effective clone of your "branch A" might have different revisions. We are working hard to decrease the cost of this ancestry lookup. We have a couple plans which will allow us to determine the revision numbers without having to look at all of history. We'll still look at more than 0 history, but if we can bound the amount of history we have to look at, it should help. (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.) John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH2jYBJdeBCYSNAAMRAh/KAJ9pK07hLXcDBZY+GqZUYWaemSXTTQCdE1U6 hO2ad7jQ6e4h+jqIgNsOYgM= =CX95 -----END PGP SIGNATURE-----