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: Workflow to accumulate individual changes? Date: Sat, 02 Jan 2010 03:28:31 +0100 Message-ID: <87fx6pi6k0.fsf@telefonica.net> References: <87bphengwq.fsf@uwakimon.sk.tsukuba.ac.jp> 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 1262399358 7199 80.91.229.12 (2 Jan 2010 02:29:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 Jan 2010 02:29:18 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 02 03:29:11 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.50) id 1NQtjp-00056y-Cy for ged-emacs-devel@m.gmane.org; Sat, 02 Jan 2010 03:29:09 +0100 Original-Received: from localhost ([127.0.0.1]:33504 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQtjp-0005XG-EX for ged-emacs-devel@m.gmane.org; Fri, 01 Jan 2010 21:29:09 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NQtjj-0005Wc-Nl for emacs-devel@gnu.org; Fri, 01 Jan 2010 21:29:03 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NQtje-0005Va-Lk for emacs-devel@gnu.org; Fri, 01 Jan 2010 21:29:02 -0500 Original-Received: from [199.232.76.173] (port=43199 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQtje-0005VT-Ie for emacs-devel@gnu.org; Fri, 01 Jan 2010 21:28:58 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:39368) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NQtje-0002lW-5e for emacs-devel@gnu.org; Fri, 01 Jan 2010 21:28:58 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.50) id 1NQtja-00052Q-3Q for emacs-devel@gnu.org; Sat, 02 Jan 2010 03:28:54 +0100 Original-Received: from 217.red-88-24-214.staticip.rima-tde.net ([88.24.214.217]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Jan 2010 03:28:54 +0100 Original-Received: from ofv by 217.red-88-24-214.staticip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 02 Jan 2010 03:28:54 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 63 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 217.red-88-24-214.staticip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (gnu/linux) Cancel-Lock: sha1:LCUJsdPwDU0GzVCQCcO9E3Pe/uA= 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:119246 Archived-At: Juanma Barranquero writes: > On Fri, Jan 1, 2010 at 13:33, Stephen J. Turnbull wrote: > >> I don't understand what you're concerned about (yes, I've seen the >> followup which includes the footnote). > > Well, if you read the note, you know what am I concerned about: not > the time for checking out the files, but the time to get the branch in > a runnable state. On my computer, "bzr branch trunk/ test/" is ~35s, > while "make bootstrap" is ~20min. The only fix for that is creating a > script to copy .o, .elc and other generated files from another branch. > Quite a fuss just to commit (and store for the future) a one-liner; > that's why I think of having a branch for these micro-issues. (Well, > colocated branches à la git would be wonderful for this case...) https://launchpad.net/bzr-loom It is underdocumented, but it works AFAIK. You can search the internet for experiences with it. OTOH, some people emulate colocated branches with `bzr switch'. The idea is that you have a checkout for hacking that you bind to wathever branch you chose to work on. For example, lets suppose that you created your working checkout with: bzr co trunk my-playground # you need to do this only once from now on, when you need a small feature, you create a branch for it: bzr branch --no-tree trunk fix-foo this is a very fast and inexpensive operation on a shared repository, as it doesn't even require to create the working tree. Now, if you want to work on `fix-foo', from `my-playground' you do bzr switch ../fix-foo you do something and, eventually bzr commit -m "done!" this will update `fix-foo'. Later, you can proced to merge the changes from `fix-foo' into `trunk' as usual (taking care of the ChangeLog issue.) If now you wish to work on a new micro-feature: cd .. # from `my-playground' bzr branch --no-tree fix-bar cd my-playground bzr status # Test that you don't have pending changes! bzr switch ../fix-bar Note that, within a shared repository, you can organize your branches as you wish, so it is advisable to make a directory `delayed-changes' and create your mini-feature branches there. [snip] -- Óscar