From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?B?TGx1w61z?= Newsgroups: gmane.emacs.devel Subject: Re: Locks on the Bzr repository Date: Tue, 24 Aug 2010 17:02:53 +0200 Message-ID: <86d3t8xdcy.wl%lluis@fulla.xlab.taz> References: <4C6D56DB.7040703@swipnet.se> <4C6D8EC5.7040901@swipnet.se> <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> <87occs5cg3.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1282662203 3112 80.91.229.12 (24 Aug 2010 15:03:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 24 Aug 2010 15:03:23 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 24 17:03:15 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 1Onv1r-00075h-4b for ged-emacs-devel@m.gmane.org; Tue, 24 Aug 2010 17:03:11 +0200 Original-Received: from localhost ([127.0.0.1]:55629 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Onv1q-0000Bd-Df for ged-emacs-devel@m.gmane.org; Tue, 24 Aug 2010 11:03:10 -0400 Original-Received: from [140.186.70.92] (port=39050 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Onv1i-0008US-Eg for emacs-devel@gnu.org; Tue, 24 Aug 2010 11:03:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Onv1d-0005qa-IF for emacs-devel@gnu.org; Tue, 24 Aug 2010 11:03:02 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:34013 helo=mail.gmx.net) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1Onv1d-0005qQ-4e for emacs-devel@gnu.org; Tue, 24 Aug 2010 11:02:57 -0400 Original-Received: (qmail invoked by alias); 24 Aug 2010 15:02:54 -0000 Original-Received: from 89.Red-83-50-198.dynamicIP.rima-tde.net (EHLO localhost) [83.50.198.89] by mail.gmx.net (mp060) with SMTP; 24 Aug 2010 17:02:54 +0200 X-Authenticated: #12333383 X-Provags-ID: V01U2FsdGVkX19wWlIoFfBwvv+jb+7Nm+E9mrb3K+TUC/9oUHB9Lb CXSl2fSpRUB5OX In-Reply-To: <87occs5cg3.fsf@uwakimon.sk.tsukuba.ac.jp> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/23.2 (i486-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. 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:129147 Archived-At: Stephen J Turnbull writes: > Llu=C3=ADs 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? > I think it's a matter of taste. After the first merge to trunk, you > have this history: > 0 -- T1 -- ... -- Tn -- 1 > \ / > B1 -- ... -- Bm > You can close the original branch, and create a new one, giving this > history: > 0 -- T1 -- ... -- Tn -- 1 -- ... -- Tp -- ... -- Tq -- 2 > \ / \ / > B1 -- ... -- Bm `---------- Fix > or you can continue on your branch > 0 -- T1 -- ... -- Tn -- 1 -- ... -- Tp -- ... -- Tq -- 2 > \ / / > B1 -- ... -- Bm -------------------------- Fix Which basically means your history will look like: 0 T1 ... Tn 1: merge feature B ... Tp ... Tq 2: fix bug on feature B no matter which of both approaches you take. Even more, one should not expect that a feature branch will be indefinitely available for committing new changes into it; which means that at some poin= t in time, the branch will have disappeared (been deleted by its creator) and fi= xes for such feature will be merged from some other sources. That is to say that the approach of multiple branches for a single feature = is more likely to happen on projects spanning an arbitrarily large amount of t= ime. [...] > The other issue is workflow. If the workflow is like Launchpad or > github, where release managers pull in whole branches from > contributors, it may make sense to use the "continued feature branch" > approach. Then both "stable" and "devel" branches can pull from your > feature branch, without polluting each other. Which would solve my question about how the same fix in multiple branches c= ould be shown nicely in the history, but at the expense of having to merge twice, and having to type twice the same merge message ("merge fix for bug N" or whatever) if you still want a "coherent" history log between branches. > In a workflow like Emacs's, where contributions go to trunk and > release manager looks for patches to cherry-pick, the "branch per fix" > approach probably makes more sense. Well, the only difference I see is that on the Emacs' workflow it is suppos= ed that developers have less means to publish their own branches, so release managers cherry-pick commits from trunk instead of merging developer's bran= ches into both trunk and stable. And I suppose the reason for such approach is to minimize the amount of work that developers require to work with bazaar instead of CVS. Lluis --=20 "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth