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: base Date: Wed, 25 Aug 2010 17:15:35 +0900 Message-ID: <87d3t75crc.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20100822120642.GA1794@muc.de> <87bp8uzu9d.fsf@mithlond.arda> <871v9o7dmf.fsf@uwakimon.sk.tsukuba.ac.jp> <87wrrg5rzg.fsf@uwakimon.sk.tsukuba.ac.jp> <87r5ho5gyr.fsf@uwakimon.sk.tsukuba.ac.jp> <87hbij6hib.fsf@uwakimon.sk.tsukuba.ac.jp> <87k4nf7ezq.fsf@catnip.gol.com> <878w3v7dd2.fsf@catnip.gol.com> <83wrrfmljv.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1282725572 30486 80.91.229.12 (25 Aug 2010 08:39:32 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 25 Aug 2010 08:39:32 +0000 (UTC) Cc: emacs-devel@gnu.org, Miles Bader To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 25 10:39:27 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 1OoBW0-0004x5-A5 for ged-emacs-devel@m.gmane.org; Wed, 25 Aug 2010 10:39:24 +0200 Original-Received: from localhost ([127.0.0.1]:46205 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OoBVz-0000Fm-Ot for ged-emacs-devel@m.gmane.org; Wed, 25 Aug 2010 04:39:23 -0400 Original-Received: from [140.186.70.92] (port=56747 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OoBVs-0000Fh-9Y for emacs-devel@gnu.org; Wed, 25 Aug 2010 04:39:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OoBVr-0000E3-3S for emacs-devel@gnu.org; Wed, 25 Aug 2010 04:39:16 -0400 Original-Received: from [130.158.254.171] (port=50490 helo=dmail02.cc.tsukuba.ac.jp) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OoBVp-0000Cz-C5; Wed, 25 Aug 2010 04:39:13 -0400 Original-Received: from imss12.cc.tsukuba.ac.jp (unknown [130.158.254.130]) by dmail02.cc.tsukuba.ac.jp (Postfix) with ESMTP id 422EBF4325; Wed, 25 Aug 2010 17:19:29 +0900 (JST) Original-Received: from imss12.cc.tsukuba.ac.jp (imss12.cc.tsukuba.ac.jp [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D1C83F4003; Wed, 25 Aug 2010 17:19:10 +0900 (JST) Original-Received: from mgmt1.sk.tsukuba.ac.jp (unknown [130.158.97.223]) by imss12.cc.tsukuba.ac.jp (Postfix) with ESMTP id C36A4F4002; Wed, 25 Aug 2010 17:19:10 +0900 (JST) Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id C0BE93FA026F; Wed, 25 Aug 2010 17:19:10 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id E0CF512049A; Wed, 25 Aug 2010 17:15:35 +0900 (JST) In-Reply-To: <83wrrfmljv.fsf@gnu.org> X-Mailer: VM undefined under 21.5 (beta29) "garbanzo" ed3b274cc037 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:129194 Archived-At: Eli Zaretskii writes: > > From: Miles Bader Date: Wed, 25 Aug 2010 09:19:37 > > +0900 > > > > I think it's related to bzr being inconsistent, complicated, and > > confusing, Yep. bzr violates about half the maxims in The Zen of Python (aka "python -m this"). That's not a crime, exactly, but it's indicative. > > with no simple mental model for users to latch onto, > > and multiple operating modes poorly stitched together (it's not > > really clear what bzr wants to be; sometimes it seems like its > > trying to be everything at once -- and, predictably, failing at > > all as a result). > > I think you simply don't like bzr, so you are inventing imaginary > problems that are present in it, but absent in other dVCSs. No. Miles exaggerates; some of the things bzr tries to do it does quite well. But the lack of a teachable mental model is a real problem, regularly visible on the bazaar list. People who like bzr a lot rarely have any idea how it works; they just happen to have workflows that fit well with a short list of bzr commands. That's nice, of course, but it is *not* easy to figure out, or explain, how to do the occasional things that don't fit one of those workflows. And it shows up in the bugs and problems that are posted to the bazaar list. Eg, I have never seen a wedged git or hg repository or branch; it is *always* possible to get back to where you started from (unless the content storage itself is corrupted). The worst that can ever happen (unless you explicitly type "git commit" to make the mess permanent) is that you've wasted hours trying to resolve an insane merge conflict. But people post regularly (recently, I'd say about once a month) asking how to get some previous version (in some cases, any version at all) checked out of their bzr branch. And in some cases the answers are very non-trivial (writing a plugin for bzr that replaces buggy functionality, for example). These are bugs, of course, but they're unimaginable in git or hg, because the history data is wedged, not the content storage. With the history data used by git, at least, wedging the history would be as criminal as wedging a list in Emacs LISP would be. But wedged history *is* occasionally reported for bazaar.