From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Uday S Reddy Newsgroups: gmane.emacs.devel Subject: Re: Locks on the Bzr repository Date: Tue, 24 Aug 2010 17:42:25 +0100 Message-ID: References: <4C6E1F0A.7070506@swipnet.se> <837hjlr78p.fsf@gnu.org> <87zkwhtws5.fsf@uwakimon.sk.tsukuba.ac.jp> <83tymppj62.fsf@gnu.org> <871v9t8klf.fsf@uwakimon.sk.tsukuba.ac.jp> <83lj81pazq.fsf@gnu.org> <83aaogpcbu.fsf@gnu.org> <87vd737pxd.fsf@uwakimon.sk.tsukuba.ac.jp> <83pqxboi38.fsf@gnu.org> <19568.59349.718000.978281@gargle.gargle.HOWL> <19570.10774.921000.853692@gargle.gargle.HOWL> <878w3x7h8u.fsf@uwakimon.sk.tsukuba.ac.jp> <19570.27753.731000.392172@gargle.gargle.HOWL> <87zkwc5xnr.fsf@uwakimon.sk.tsukuba.ac.jp> <86hbikxk3k.wl%lluis@fulla.xlab.taz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1282668181 30312 80.91.229.12 (24 Aug 2010 16:43:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 24 Aug 2010 16:43:01 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 24 18:43:00 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 1OnwaS-0004Qx-10 for ged-emacs-devel@m.gmane.org; Tue, 24 Aug 2010 18:43:00 +0200 Original-Received: from localhost ([127.0.0.1]:33097 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnwaR-0005Nu-FO for ged-emacs-devel@m.gmane.org; Tue, 24 Aug 2010 12:42:59 -0400 Original-Received: from [140.186.70.92] (port=58195 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnwaA-0005Fv-1N for emacs-devel@gnu.org; Tue, 24 Aug 2010 12:42:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Onwa8-0004f4-L4 for emacs-devel@gnu.org; Tue, 24 Aug 2010 12:42:41 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:56888) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Onwa8-0004ey-Ao for emacs-devel@gnu.org; Tue, 24 Aug 2010 12:42:40 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Onwa7-0004An-1V for emacs-devel@gnu.org; Tue, 24 Aug 2010 18:42:39 +0200 Original-Received: from acws-0068.cs.bham.ac.uk ([147.188.194.56]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Aug 2010 18:42:38 +0200 Original-Received: from U.S.Reddy by acws-0068.cs.bham.ac.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Aug 2010 18:42:38 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 37 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: acws-0068.cs.bham.ac.uk User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (windows-nt) Cancel-Lock: sha1:Aa56IoY4g+Zqoutyku2tn4GXUM0= X-detected-operating-system: by eggs.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:129157 Archived-At: Lluís writes: > Just to make sure I understand it. Suppose I'm working on a branch > with a fairly large set of changes and it has been merged back to > trunk. After a while a bug is found on my code, which was not > thoroughly tested, or a new relatively minor functionality is added > related to the code on my branch. Should this be committed on my > branch and then followed with a merge to trunk? Or should this live > in a completely new branch that will be merged back to trunk once > it's well tested? In Bazaar, it is fine to continue adding to a branch after it has been merged once. Next time it is merged, Bazaar can figure out which revisions are new and merge them appropriately. > Now that I think of it, I think I start to see the reason for nested > history and the suggestion of not using rebase. Even for the > smallest bug fix or feature addition, a full branch should be > created, and every change should be thoroughly tested in > there. Then, trunk would be composed of just merge messages like > "add subsystem Y", "add feature X to subsystem Y", "fix bug N on > Y". This would produce a log in trunk that would very closely > resemble the contents of a NEWS file, but at the expense of a strict > branch/test/merge discipline, which is not bad per-se. There is no harm in creating task branches for individual bug fixes. But, that in itself doesn't make one virtuous. The crucial testing to be done is *after you merge it into trunk*. Testing in the task branch is not enough. Every time you do pull/update/merge, you need to test again. The workflow recommended for "Quick Fixes" in the Wiki has no logical problem, even though it avoids task branches. Its only problem is that it is slow, especially when used with an sftp server. Cheers, Uday