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 19:47:56 +0100 Message-ID: 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> <868w3wx7cs.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 1282675701 30405 80.91.229.12 (24 Aug 2010 18:48:21 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 24 Aug 2010 18:48:21 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 24 20:48: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 1OnyXi-0006yH-Nn for ged-emacs-devel@m.gmane.org; Tue, 24 Aug 2010 20:48:19 +0200 Original-Received: from localhost ([127.0.0.1]:48635 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnyXi-0000tG-13 for ged-emacs-devel@m.gmane.org; Tue, 24 Aug 2010 14:48:18 -0400 Original-Received: from [140.186.70.92] (port=49213 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnyXb-0000sq-BU for emacs-devel@gnu.org; Tue, 24 Aug 2010 14:48:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OnyXY-0006Wa-LR for emacs-devel@gnu.org; Tue, 24 Aug 2010 14:48:11 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:39709) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OnyXY-0006W9-AH for emacs-devel@gnu.org; Tue, 24 Aug 2010 14:48:08 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OnyXV-0006nW-Ob for emacs-devel@gnu.org; Tue, 24 Aug 2010 20:48:05 +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 20:48:05 +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 20:48:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 42 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:7oVSTO6R5O/a2Uz198H8GT3+VSM= 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:129170 Archived-At: Lluís writes: > Sure, my only concern is on how the history will look like. Suppose > I have commits (f1, f2, f3) implemeting some feature. These are > merged into trunk as revision f. Then I fix a simple bug on the > feature (ff11) and merge again as ff1. Fix another bug with multiple > commits (ff21, ff22) and fix another one with a single commit > (ff31). If now I merge, both fixes are merged into trunk, and > supposing they are independent from each other, ideally they should > appear as two different entries on the history in trunk (ff2 and > ff3). If you want ff2 and ff3 to appear as separate merges in the history, then you merge them separately. But they can all sit in the same feature branch at your end. In my context, I often want to review the contributions that our people send in (via Bazaar branches on Launchpad). There I prefer if they do all their work of a particular feature in a single branch. Then I can just pull it into my local copy, review it and merge it in. If they make a new branch for each fix, it will add additional set-up cost for me to make a copy of their branch. I might also mention that it was in this context that I first used rebase. Since the contributions are often based on some old revision in the trunk, which is a pain to go back to, I first rebase my copy of their branch to the current state of the trunk. Then I review and test each commit, before merging it in. I think this is a great application of rebase. Not only is it safe (because rebase is done before review), it is a lot better than merge which will just plonk everything together and hope for the best! > Of course, this is all to, at the end, have a history in trunk that > is shown as: ... f ... ff1 .... ff2 .... ff3 ... > > so that history quickly shows at a high level what has been changed just by > looking at the "first level" of the history. Sounds perfect! Cheers, Uday