From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Strange message from "bzr pull" Date: Tue, 29 Dec 2009 20:28:32 +0100 Message-ID: <87y6klo9zz.fsf@telefonica.net> References: <877hs5ogv8.fsf@red-bean.com> <83my11ejmr.fsf@gnu.org> <83ljgleiir.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1262114967 10921 80.91.229.12 (29 Dec 2009 19:29:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Dec 2009 19:29:27 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 29 20:29:19 2009 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.50) id 1NPhkt-0001R7-6o for ged-emacs-devel@m.gmane.org; Tue, 29 Dec 2009 20:29:19 +0100 Original-Received: from localhost ([127.0.0.1]:35356 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NPhkt-0005y5-5k for ged-emacs-devel@m.gmane.org; Tue, 29 Dec 2009 14:29:19 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NPhkm-0005xs-0w for emacs-devel@gnu.org; Tue, 29 Dec 2009 14:29:12 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NPhkg-0005xB-Vf for emacs-devel@gnu.org; Tue, 29 Dec 2009 14:29:11 -0500 Original-Received: from [199.232.76.173] (port=51607 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NPhkg-0005x7-NF for emacs-devel@gnu.org; Tue, 29 Dec 2009 14:29:06 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:56870) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NPhkg-0007wT-E1 for emacs-devel@gnu.org; Tue, 29 Dec 2009 14:29:06 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.50) id 1NPhkb-0001KW-Rj for emacs-devel@gnu.org; Tue, 29 Dec 2009 20:29:01 +0100 Original-Received: from 174.red-83-45-255.dynamicip.rima-tde.net ([83.45.255.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 29 Dec 2009 20:29:01 +0100 Original-Received: from ofv by 174.red-83-45-255.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 29 Dec 2009 20:29:01 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 34 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 174.red-83-45-255.dynamicip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (gnu/linux) Cancel-Lock: sha1:7IH47hJJPdHmXdR/gvDBrR58uR4= 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:118964 Archived-At: Eli Zaretskii writes: >> > It sounds a pity to have a tree that is never used in any way.  It >> > just wastes disk space. >> >> But on the proposed workflow, the tree *is* used. To merge the changes >> from the task branches, and to commit upstream. > > I don't know enough about bzr internals, but I was under the > impression that the tree-less repository has all the information > needed for that, albeit not in the form of the Emacs source files. Merging may cause conflicts, which require editing files. This is why you need the source files on that branch. [snip] On the topic of spoon-feeding the developers with bzr recipes, I think it is quite pertinent if the recipe is simple enough. BzrForEmacsDevs is not simple enough for people who have CVS incorporated into their DNA. IMHO it lacks some clear explanation of the new concepts (revisions, branches, merges, histories, divergence, etc) so they can figure out what's going on, see most of the new possibilities and ask to the "gurus" for advice using a discernible language when they cannot decide among several options. Using a new workflow without a sufficient understanding of the basic concepts may cause mistakes and frustration. Maybe a pointer to some generic introduction to DVCS plus a description of how Bazaar implements it would be okay (I don't know any such decent introduction specific for Bazaar, though.) -- Óscar