From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: What have the Romans done for us? (Bazaar) Date: Tue, 6 Apr 2010 14:31:44 +0000 Message-ID: <20100406143144.GB3551@muc.de> References: <20100405145637.GA3248@muc.de> <87mxxhhq3b.fsf@red-bean.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1270563818 12421 80.91.229.12 (6 Apr 2010 14:23:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 6 Apr 2010 14:23:38 +0000 (UTC) Cc: emacs-devel@gnu.org To: Karl Fogel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 06 16:23:33 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 1Nz9gi-0000Pk-P5 for ged-emacs-devel@m.gmane.org; Tue, 06 Apr 2010 16:23:33 +0200 Original-Received: from localhost ([127.0.0.1]:41872 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nz9gi-0001l5-1s for ged-emacs-devel@m.gmane.org; Tue, 06 Apr 2010 10:23:32 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nz9gb-0001jt-72 for emacs-devel@gnu.org; Tue, 06 Apr 2010 10:23:25 -0400 Original-Received: from [140.186.70.92] (port=46616 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nz9gY-0001hA-IJ for emacs-devel@gnu.org; Tue, 06 Apr 2010 10:23:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nz9gW-0005T7-9O for emacs-devel@gnu.org; Tue, 06 Apr 2010 10:23:22 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:1030 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nz9gV-0005Sn-Us for emacs-devel@gnu.org; Tue, 06 Apr 2010 10:23:20 -0400 Original-Received: (qmail 51723 invoked by uid 3782); 6 Apr 2010 14:23:18 -0000 Original-Received: from acm.muc.de (pD9E50443.dip.t-dialin.net [217.229.4.67]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Tue, 06 Apr 2010 16:23:16 +0200 Original-Received: (qmail 4690 invoked by uid 1000); 6 Apr 2010 14:31:44 -0000 Content-Disposition: inline In-Reply-To: <87mxxhhq3b.fsf@red-bean.com> User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 4.6-4.9 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:123265 Archived-At: Hi, Karl, On Mon, Apr 05, 2010 at 11:32:56AM -0400, Karl Fogel wrote: > Alan Mackenzie writes: > >Would somebody please remind me of all the advantages Bazaar has over > >CVS, all the wonderful things it enables one to do. This request is still open. ;-) > >Right at the moment, it just seems like a slow, slow, slow and buggy > >replacement for CVS, which consumes several hundred megabytes of my > >disk space more than CVS did. > If you don't typically have multiple different branches going at once, > then there is no space advantage to Bzr. (On the other hand, for some > people there are advantages to having all the history locally, though > those may not be advantages for you.) Working-tree + repository > working-tree. There is NO space advantage in duplicating the repository over everybody's machines. It's the sluggishness which really bothers me. Is it decompressing which is taking all this time? If so, we could do with an option to store in decompressed format, for those like me who have more disk space than processing power. > > bzr log is so slow (40 seconds) as to be only somewhat useful. > Hmm. On my 4-year-old IBM ThinkPad R60 running Debian GNU/Linux: > $ time bzr log -n0 --show-ids > log-n0.out > real 0m25.147s > user 0m23.173s > sys 0m1.540s > $ > That's for the entire history of the project. 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. > I don't have a CVS tree handy to test with, but my memory is CVS was > not faster at that operation -- though of course, CVS had to go over > the network, so it's hard to compare, really. What exact log > operations are slow for you vs the comparable CVS operations? My impression is that it was faster to open a web browser, get to the savannah CVS interface and get the log for a particular file starting to display on the screen than to get the first output from 'bzr log'. It's not really the total time that irks, rather the time to start displaying. > (A non-rhetorical question, by the way. I believe you when you say > it's slow, I just want to narrow down what "it" is.) Always the best sort of question. :-) $ time bzr log -n0 --show-ids > /dev/null real 1m42.421s user 1m36.229s sys 0m2.503s $ time bzr log -n0 --show-ids lisp/progmodes/cc-engine.el > /dev/null real 0m38.924s user 0m38.276s sys 0m0.538s That is so slow it almost transforms an interactive shell into batch mode. > >Worst of all is the lack of a proper fine manual; what there is is > >available only in html or "bzr help", neither of which is properly > >searchable; what there is is also bloated and vague and generally of > >low quality. > ? http://doc.bazaar.canonical.com/en/ points to plenty of downloadable > documentation, in HTML, CHM, and PDF formats. They all lack hyperlinks or are non-searchable. (BTW, I'll need to find out what CHM is). But worst of all is the low quality of the reference docs. For example, 'bzr help merge' doesn't say with any specificity what is being merged or where the result is written. It talks about "merging a branch", which makes as much sense as "the difference between a file" does. 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? > >Anybody know a mail address to get in touch with the bazaar team? > Sure: Thanks! > I report bzr bugs at https://bugs.edge.launchpad.net/bzr/+filebug (well, > I navigate my way there from the Bazaar project home page, but that's > the page I'm aiming for). I don't use any "script running in a > web-browser"; not sure what you're referring to. I'm referring to that same page. It doesn't work in my browser. See my reply to RMS. > IMHO it's fine to just describe your bug on that mailing list. Thanks! > >So, yes, bzr is wonderful, because it's a DISTRIBUTED VCS, and > >distributed VCSs are Good Things. Would somebody please remind me why? > Well, if you don't like doing the new things that DVCS allows you to do, > then yeah, there aren't any advantages :-). For those who like having > all history locally, being able to make and merge task branches, being > able to easily push fully-versioned trees to other places, etc, it's > much better. I personally would never want to go back. (I also like > the truly atomic commits with unambiguous identifying handles, though > that isn't specific to DVCS of course.) > But I can certainly see how there are some developers for whom these > things are not a step forward. My question wasn't rhetorical. ;-) I'd like having local history if I could access it in less than historical time, and I do appreciate atomic "commit"s (even though "commit" has had its meaning substantially changed from CVS). Then again, I don't know what "push" means in bzr; "update a mirror of this branch"? I'm sure I'll solve this puzzle when I put enough mental effort into it, and how it differs from "merge". > (Also, some of us like the better sanitation and medicine and education > and irrigation and public health and roads and a freshwater system and > baths and public order...) Indeed! > -Karl -- Alan Mackenzie (Nuremberg, Germany).