From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Locks on the Bzr repository Date: Tue, 24 Aug 2010 23:10:04 +0900 Message-ID: <87occs5cg3.fsf@uwakimon.sk.tsukuba.ac.jp> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1282659231 20707 80.91.229.12 (24 Aug 2010 14:13:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 24 Aug 2010 14:13:51 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?Llu=EDs?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 24 16:13:50 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 1OnuG4-0002oX-LZ for ged-emacs-devel@m.gmane.org; Tue, 24 Aug 2010 16:13:49 +0200 Original-Received: from localhost ([127.0.0.1]:55601 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnuG3-00045e-Ka for ged-emacs-devel@m.gmane.org; Tue, 24 Aug 2010 10:13:47 -0400 Original-Received: from [140.186.70.92] (port=32957 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnuFu-000432-8V for emacs-devel@gnu.org; Tue, 24 Aug 2010 10:13:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OnuFs-0007KI-8u for emacs-devel@gnu.org; Tue, 24 Aug 2010 10:13:38 -0400 Original-Received: from imss12.cc.tsukuba.ac.jp ([130.158.254.161]:38649) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OnuFr-0007Je-Oz for emacs-devel@gnu.org; Tue, 24 Aug 2010 10:13:36 -0400 Original-Received: from imss12.cc.tsukuba.ac.jp (imss12.cc.tsukuba.ac.jp [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B82CBF4003; Tue, 24 Aug 2010 23:13:33 +0900 (JST) Original-Received: from mgmt1.sk.tsukuba.ac.jp (unknown [130.158.97.223]) by imss12.cc.tsukuba.ac.jp (Postfix) with ESMTP id 9F16CF4002; Tue, 24 Aug 2010 23:13:33 +0900 (JST) Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 937723FA0251; Tue, 24 Aug 2010 23:13:33 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 002881A47B8; Tue, 24 Aug 2010 23:10:04 +0900 (JST) In-Reply-To: <86hbikxk3k.wl%lluis@fulla.xlab.taz> X-Mailer: VM undefined under 21.5 (beta29) "garbanzo" ed3b274cc037 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:129139 Archived-At: Llu=EDs 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 with very similar effect (bzr knows that B1 ... Bm are already in Tq, so it will apply effectively apply the patch (Bm -> Fix) to Tq). The main difference is that you could have a conflict between Fix and some patch between 1 and Tp in the "continued feature branch" case, but you would take the changed code into account in producing Fix for the "make new branch for fix" case. In the common case that nobody touches "your" code between 1 and Tq, these are 100% equivalent. 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. 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. > 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. Thoroughly tested, yes, but remember, it is never possible to fully test in a feature branch (unless the feature branch is the first continuation applied to the tip of the trunk it branched from). > 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. I believe that's very much the way the Bazaar developers think of it.