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: What have the Romans done for us? (Bazaar) Date: Thu, 08 Apr 2010 03:47:59 +0900 Message-ID: <871verp09s.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20100405145637.GA3248@muc.de> <87mxxhhq3b.fsf@red-bean.com> <20100406143144.GB3551@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1270666797 23264 80.91.229.12 (7 Apr 2010 18:59:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 7 Apr 2010 18:59:57 +0000 (UTC) Cc: Karl Fogel , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 07 20:59:55 2010 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.69) (envelope-from ) id 1NzaTh-00081v-Lm for ged-emacs-devel@m.gmane.org; Wed, 07 Apr 2010 20:59:55 +0200 Original-Received: from localhost ([127.0.0.1]:60845 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NzaTg-0004sF-5N for ged-emacs-devel@m.gmane.org; Wed, 07 Apr 2010 14:59:52 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NzaK7-0006Pk-TO for emacs-devel@gnu.org; Wed, 07 Apr 2010 14:50:00 -0400 Original-Received: from [140.186.70.92] (port=52013 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NzaK6-00065U-Bh for emacs-devel@gnu.org; Wed, 07 Apr 2010 14:49:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NzaJ4-0006Kt-P8 for emacs-devel@gnu.org; Wed, 07 Apr 2010 14:48:56 -0400 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:36750) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NzaJ2-0006Kd-RW for emacs-devel@gnu.org; Wed, 07 Apr 2010 14:48:54 -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 F0CA91535A8; Thu, 8 Apr 2010 03:48:50 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 92A151A25EA; Thu, 8 Apr 2010 03:47:59 +0900 (JST) In-Reply-To: <20100406143144.GB3551@muc.de> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" a03421eb562b XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/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:123320 Archived-At: Alan Mackenzie writes: > It seems the time taken is only weakly dependent on what you're logging > over. I was just getting logs for a single file, > .../lisp/progmodes/cc-engine.el. As Eli points out, you need to learn (at least a little bit) how to "think Bazaar". In CVS getting logs for a single file is faster than for the whole project because you only get the logs you want, from one ,v file. In Bazaar, getting logs for a single file is more costly than getting them for the whole project because you have to get all the logs, then filter out the uninteresting ones. This is because you do not commit changes to a file in Bazaar (or any of the other dVCSes); you commit all the changes to the tree. There's only one log for all the history of the branch. Also, "bzr log -n0" is *much* slower than "bzr log" because the former needs[1] to compute the whole history DAG to decide where to put each commit before displaying them, while the latter just chases the principal parent chain, and can start displaying log entries immediately. > This vagueness is prevalent over much or all of 'bzr help '. > Is it too much to expect these man pages (in effect) to be precise? Currently, yes. The developers are aware that the docs have some problems, and some progress is being made. > > >So, yes, bzr is wonderful, because it's a DISTRIBUTED VCS, and > > >distributed VCSs are Good Things. Would somebody please remind me why? Sure. The direct benefit is that you can work on a branch with little effort, temporarily isolating the changes you're working on from interference with others' work. You can choose when to pull upstream changes into your branch, and which changes to accept. In CVS (or SVN up to 1.4 or so), pulling multiple times will usually result in annoying, unnecessary merge conflicts. You can also choose to pull from multiple upstreams (which all must be branches off the same mainstream, of course), and integrate those changes. It is this last integrative function that is most characteristic of dVCS (SVN still can't do this very well, and not at all across separately administered mirrors). The indirect benefit is a substantial savings in time and frustration for developers who enjoy the direct benefits, and that means more rapid delivery of new code to all users, including you. > My question wasn't rhetorical. ;-) I'd like having local history if I > could access it in less than historical time, That way of stating it is quite rhetorical, though. Footnotes: [1] "Needs" in the current implementation. It's possible to improve this, and some work is being done at the moment.