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: bzr repository ready? Date: Sat, 21 Nov 2009 17:45:11 +0100 Message-ID: <87vdh36d48.fsf@telefonica.net> References: <87639fr3w7.fsf@red-bean.com> <87vdhfpil2.fsf@red-bean.com> <87einvxy9c.fsf@red-bean.com> <20091118230952.GB908@muc.de> <87my2jw05z.fsf@red-bean.com> <83skc9pbf7.fsf@gnu.org> <87iqd5vw5n.fsf@red-bean.com> <877htl53tc.fsf@telefonica.net> <87ws1ku7zd.fsf@red-bean.com> <87hbso4s13.fsf@telefonica.net> <83aaygoy90.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 1258822075 414 80.91.229.12 (21 Nov 2009 16:47:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Nov 2009 16:47:55 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 21 17:47:48 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 1NBt7j-0008QK-8r for ged-emacs-devel@m.gmane.org; Sat, 21 Nov 2009 17:47:47 +0100 Original-Received: from localhost ([127.0.0.1]:58514 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NBt7i-0006NK-Rl for ged-emacs-devel@m.gmane.org; Sat, 21 Nov 2009 11:47:46 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NBt7C-0006CM-Be for emacs-devel@gnu.org; Sat, 21 Nov 2009 11:47:14 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NBt77-0006AK-G8 for emacs-devel@gnu.org; Sat, 21 Nov 2009 11:47:13 -0500 Original-Received: from [199.232.76.173] (port=40294 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NBt77-0006AC-96 for emacs-devel@gnu.org; Sat, 21 Nov 2009 11:47:09 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:33813) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NBt76-0003Tx-Lk for emacs-devel@gnu.org; Sat, 21 Nov 2009 11:47:09 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.50) id 1NBt74-0008E4-Dr for emacs-devel@gnu.org; Sat, 21 Nov 2009 17:47:06 +0100 Original-Received: from 153.red-88-24-228.staticip.rima-tde.net ([88.24.228.153]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 Nov 2009 17:47:06 +0100 Original-Received: from ofv by 153.red-88-24-228.staticip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 Nov 2009 17:47:06 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 57 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 153.red-88-24-228.staticip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) Cancel-Lock: sha1:6gE/0Zn0Nssn19ljkDlwyyoZKkM= 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:117450 Archived-At: Eli Zaretskii writes: >> For large compiled projects such as Emacs, the use of feature branches >> is not that great. First, building takes a long time. > > Why does the building take a long time in that case? > >> Second, it imposes a large penalty on those who just want to hack >> some elisp. > > What penalty is that? Let's suppose that you want to do some lightweight hacking on a elisp component of emacs. The `feature branch' workflow says that you create a new local branch specifically for that: bzr branch path/to/my/local/emacs/mirror fix-bug-3429 and then you edit the .el files. But at some point you want to test them, and for that you need an emacs executable. Now, building emacs is not a fast operation even on a GNU/Linux modern desktop (let's not mention Windows). Hence, even when you start the build right after the feature branch creation, it is possible that you end your modifications before the build ends. This certainly will occur often on slow GNU/Linux machines and even on fast Windows machines. Maybe emacs has a mechanism for executing it using a uncompiled elisp source tree that resides on other directory. If that is the case, you could use a pre-existent emacs executable for testing your changes. >> Maybe a system based on `bzr switch' is the solution for Emacs, >> although it is not so simple to understand as feature branches. For >> the diehard CVS users, beginning with a single work branch is the >> solution. `bzr shelve' would help them > > I'd appreciate some more details on that. It's hard to make up your > mind about the usage patterns with so many new factors being > introduced in ever sentence without any explanations. (And yes, I did > read the Bazaar User Reference for these two commands, but it's just > awful: "bzr shelve" does not describe its argument FILE, "bzr switch" > does not tell what is its argument TO_LOCATION, etc. The User Guide > helps a bit, but you cannot search in it, at least not in the on-line > version.) I guess that this is yet another case of "having lots of options is counter-producing for the uninformed". I was thinking on writing an incremental guide for those who know nothing about DVCSs and bzr in particular, beginning with the most simple workflows and evolving step by step to the sophisticated ones, explaining the advantages that each level brings over the previous one. This way each hacker could choose his own workflow basing the decission on some solid info. But my English is awful. If I could write on Spanish and some volunteer translate it to English... -- Óscar