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: Locks on the Bzr repository Date: Tue, 24 Aug 2010 15:25:56 +0200 Message-ID: <87tymkf8gr.fsf@telefonica.net> References: <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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1282656382 6081 80.91.229.12 (24 Aug 2010 13:26:22 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 24 Aug 2010 13:26:22 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 24 15:26:20 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 1OntW7-0006CX-KH for ged-emacs-devel@m.gmane.org; Tue, 24 Aug 2010 15:26:19 +0200 Original-Received: from localhost ([127.0.0.1]:34681 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OntW6-0005xh-Q6 for ged-emacs-devel@m.gmane.org; Tue, 24 Aug 2010 09:26:18 -0400 Original-Received: from [140.186.70.92] (port=44922 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OntVy-0005vw-Dh for emacs-devel@gnu.org; Tue, 24 Aug 2010 09:26:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OntVx-0000ag-CI for emacs-devel@gnu.org; Tue, 24 Aug 2010 09:26:10 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:59782) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OntVw-0000aG-Vt for emacs-devel@gnu.org; Tue, 24 Aug 2010 09:26:09 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OntVv-0005w9-7n for emacs-devel@gnu.org; Tue, 24 Aug 2010 15:26:07 +0200 Original-Received: from 83.38.73.98 ([83.38.73.98]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Aug 2010 15:26:07 +0200 Original-Received: from ofv by 83.38.73.98 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Aug 2010 15:26:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 31 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 83.38.73.98 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:RnTztWq187ArfavdqKy6TCz8BaI= 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:129132 Archived-At: Lluís writes: [snip] > 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? 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, > the nice messages from emacs-23 are lost once merged into trunk, > right? To see them you'll need the -n0 switch, yes. This is an important case that breaks the "niceness" of having a privileged arm on the DAG. > 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... I > imagine this is exactly the place where rebase makes sense (merge new > branch into emacs-23, then rebase emacs-23 into trunk), but this > should in fact be an operation that is performed only by a small set > of developers. Rebasing has the undesirable effect of changing the identity of the commits, so it is no longer possible to easily test the presence of one change on several branches ("is commit 388743FA2 present in this branch?") This is another reason for never rebasing commits that were released to the public. So no, I don't think that `rebase' would be the right tool for keeping a nice bzr log on the emacs-23/trunk exchange of commits. [snip]