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:25:28 +0200 Message-ID: <86bp8sxcbb.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> <86fwy4xisg.wl%lluis@fulla.xlab.taz> <87mxsc5c1x.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 1282663545 9372 80.91.229.12 (24 Aug 2010 15:25:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 24 Aug 2010 15:25:45 +0000 (UTC) Cc: "Stephen J. Turnbull" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 24 17:25:44 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 1OnvNe-0002CK-4n for ged-emacs-devel@m.gmane.org; Tue, 24 Aug 2010 17:25:43 +0200 Original-Received: from localhost ([127.0.0.1]:51746 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnvNb-00073t-Ci for ged-emacs-devel@m.gmane.org; Tue, 24 Aug 2010 11:25:39 -0400 Original-Received: from [140.186.70.92] (port=40434 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnvNV-00072e-CC for emacs-devel@gnu.org; Tue, 24 Aug 2010 11:25:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OnvNU-00010g-1f for emacs-devel@gnu.org; Tue, 24 Aug 2010 11:25:33 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:59431 helo=mail.gmx.net) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1OnvNT-00010T-LG for emacs-devel@gnu.org; Tue, 24 Aug 2010 11:25:31 -0400 Original-Received: (qmail invoked by alias); 24 Aug 2010 15:25:28 -0000 Original-Received: from 89.Red-83-50-198.dynamicIP.rima-tde.net (EHLO localhost) [83.50.198.89] by mail.gmx.net (mp008) with SMTP; 24 Aug 2010 17:25:28 +0200 X-Authenticated: #12333383 X-Provags-ID: V01U2FsdGVkX195bwJWZwV5V6HpdnW+qmecNmnoENCa/3vKBa1tHL Kr49zRucS33ul1 In-Reply-To: <87mxsc5c1x.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:129149 Archived-At: Stephen J Turnbull writes: > Llu=C3=ADs writes: >> If a bug is fixed on the release branch (emacs-23) using branch >> merges, so that the history of emacs-23 will read "fix bug N", how >> can the same history clarity be maintained in trunk? > See my previous reply for a brief discussion. >> I mean, both the emacs-23 branch and trunk would like to benefit >> from fixing those bugs, but if the release branch is merged into >> trunk, > No, you essentially never want to do that. The trunk will diverge > quickly from the release branch. It has better (but risky) fixes for > some bugs, new features requiring changed APIs, etc. However, some > changes to the release branch will depend on the old code, and trying > to merge that into the trunk will create One Big Mess. (This is what > "merge branches" *means*: *all* of the code needs to be merged, not > just the "good" code you want.) Ah, you're right. >> the nice messages from emacs-23 are lost once merged into >> trunk, right? > I don't understand what you mean by "losing the messages". The > messages are part of the commit object, and come with it in a merge. I meant that, for example, you merge in a branch for a bugfix into the stab= le branch. The log in stable will say something like "fix bug N", although this might be composed of various commits. Then, you merge stable into trunk, but merging will no longer show "fix bug N" on the leftmost part of the history= in bazaar, so any changes in stable from last merge into trunk will all be "hi= dden" under a single "merge from stable", instead of having now a history on trunk that shows what exactly has modified in stable and merged into trunk. Of course, this will not happen with a merge from release into trunk (for t= he reasons you explained), but still can happen for any other set of 3 or more branches; as long as the branch "relation chain" is shorter than 3 levels, everything's OK, but that's essentially a flat model where every feature/fi= x is on its own branch (which is never a release nor a trunk branch) and those feature/fix branches must be merged multiple times, one into each release/t= runk branch where you want to see that change. This approach can produce exceptionally nice history logs (in the sense tha= t bzr hides history messages "inside" a merge), but it seems to me that at the ex= pense of a higher managing effort. Of course that effor might already be there on any other approach/workflow,= it's just that this is my first encounter with DVCS. >> And merging the new feature/fix branch into both emacs-23 and trunk >> would provide the desired history structure outcome, but this is >> kind of troublesome as the merge operation must be performed >> twice... > This is true, anyway. The nature of branches is that they diverge, > and the changes that are appropriate diverge, too. Then you're in favour of the "flat" model I described above. >> I imagine this is exactly the place where rebase makes sense (merge >> new branch into emacs-23, then rebase emacs-23 into trunk), > Actually, most projects do this in the opposite direction. Features > and fixes go into trunk, first, typically at developer discretion. > Then the release manager picks ("cherry-picks") the bug fixes > appropriate from the release branch. Completely right, because of what you pointed out on your second paragraph. 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