From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: What have the Romans done for us? (Bazaar) Date: Wed, 07 Apr 2010 02:33:53 -0400 Message-ID: References: <20100405145637.GA3248@muc.de> <87mxxhhq3b.fsf@red-bean.com> <20100406143144.GB3551@muc.de> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1270622066 12826 80.91.229.12 (7 Apr 2010 06:34:26 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 7 Apr 2010 06:34:26 +0000 (UTC) Cc: kfogel@red-bean.com, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 07 08:34:25 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 1NzOqE-00089V-L1 for ged-emacs-devel@m.gmane.org; Wed, 07 Apr 2010 08:34:23 +0200 Original-Received: from localhost ([127.0.0.1]:57871 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NzOqD-00024S-UN for ged-emacs-devel@m.gmane.org; Wed, 07 Apr 2010 02:34:21 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NzOq5-000249-Vg for emacs-devel@gnu.org; Wed, 07 Apr 2010 02:34:14 -0400 Original-Received: from [199.232.76.173] (port=58028 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NzOq5-000241-BN for emacs-devel@gnu.org; Wed, 07 Apr 2010 02:34:13 -0400 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NzOpm-0007AX-I0 for emacs-devel@gnu.org; Wed, 07 Apr 2010 02:33:58 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:40361) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NzOpm-0007AT-6j for emacs-devel@gnu.org; Wed, 07 Apr 2010 02:33:54 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.69) (envelope-from ) id 1NzOpl-0004gH-Mf; Wed, 07 Apr 2010 02:33:53 -0400 In-reply-to: <20100406143144.GB3551@muc.de> (message from Alan Mackenzie on Tue, 6 Apr 2010 14:31:44 +0000) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:123304 Archived-At: > Date: Tue, 6 Apr 2010 14:31:44 +0000 > From: Alan Mackenzie > Cc: emacs-devel@gnu.org > > 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. ;-) See below, for my humble attempt. First, some responses to specific issues. > Working-tree + repository > working-tree. There is NO space advantage in > duplicating the repository over everybody's machines. The advantage is that you can do VCS operations locally. I mention some of them below. I also hope that the disk space is not the issue, nowadays. (In any case, we don't replicate the repository, only part of it -- specifically, only the bound branches you have. All the other branches are not on your disk.) > It's the sluggishness which really bothers me. Is it decompressing > which is taking all this time? No. It's the network traffic. Fire up some resource monitoring tool while you are waiting for "bzr up", and you will see that the CPU is most of the time idle. If it were decompressing, it would be visible in the CPU load. Another data point: when I do "bzr up" on a machine that is on a very high-speed connection (in the US), it is much, much faster, as fast as CVS or faster. > 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. "Doctor, it hurts when I do like this". -- "Well, then don't do that." Don't use the -n0 switch to "bzr log" unless you really, really, REALLY have to. The -n0 switch is very expensive. I think it causes bzr to read large portion of the branch's meta-data. If nothing else, this defeats the advantage of a warm cache -- which I believe was the point Andreas was making with his comparative timings. I found that I almost never need to use -n0. It is only necessary if you want to look into changes that came from merged branches. With the Emacs almost-linear development on the trunk mainline, it is unnecessary most of the time. Without -n0, "bzr log" is _much_ faster, and the warm cache does speed it up considerably. > > >So, yes, bzr is wonderful, because it's a DISTRIBUTED VCS, and > > >distributed VCSs are Good Things. Would somebody please remind me why? > > My question wasn't rhetorical. ;-) Let me try to give you my answer. But first, some personal philosophical digression: When you begin using a new non-trivial system, you need to learn to think according to that system's rules, and use the paradigms appropriate for that system. If you try to stick to thinking and paradigms borrowed from some other system, you will most of the time be disappointed. To take a trivial example: if you switch to Lisp from C, you should learn to "think Lisp". If you keep "thinking C" and write C programs in Lisp, you will most probably think that Lisp is ``just a slow, slow replacement for C'', with awkward syntax and annoying misfeatures (like the fact that symbols have global scope by default), which just eats up lots of memory. Sounds familiar? Observe: > > >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. So don't "think CVS", "think bzr" instead. Try to find work patterns that hit less on bzr's disadvantages and instead make good use of its advantages. "bzr up" is slow? do it less often, and instead rely on local commits for your routine development. After all, who said everybody and their dog need to see every feature you develop and every bug you patch right away? This means do more work in a local branch and less in the trunk. bzr favors this pattern; CVS very much defeated it, so you probably didn't think about using it as a matter of routine. Other advantages of bzr that should really change the way you think about your workflow are that you have all the history locally, and that branching is very cheap. That means, if you want to see how something worked or didn't work in some past version, you can have that in seconds -- something which would take much longer with CVS, and therefore not hardwired into our CVS-oriented habits. It also means that you can have several local branches, one each for every set of features you develop, yet another branch for testing crazy ideas and throwing them away (with a single "bzr revert" command), etc. etc. One thing that remains to be relatively painful is bootstrapping a fresh branch. That is the only "fly in the ointment" of "branching is cheap" idea. However, on GNU/Linux a bootstrap is still quite fast, so perhaps this is not a problem for you. If it is, explore the co-located branches features in bzr ("bzr switch" etc.). Me, I just have several branches bootstrapped in advance, which I can reuse whenever I need to. "bzr pull --overwrite" will make any branch a copy of the current trunk in a matter of seconds, and almost never require a bootstrap. Once I have a fresh branch, I can do there whatever I like. The fact that switching between different versions is fast and cheap means that bisecting to find a change that matters should have much more place in your routine workflow than it ever could with CVS. Bottom line, instead of trying to bend bzr and keep your CVS-vintage habits, "think bzr" and change your habits to fit this new tool. That is what I did, and although I'm still far from seeing the end of the journey (and yes, the quality of bzr docs makes it harder), I do see improvements in the quality of my life as a developer. HTH