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: Mon, 23 Aug 2010 13:41:13 +0100 Message-ID: <19570.27753.731000.392172@gargle.gargle.HOWL> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1282567728 21350 80.91.229.12 (23 Aug 2010 12:48:48 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 23 Aug 2010 12:48:48 +0000 (UTC) Cc: Uday S Reddy , emacs-devel@gnu.org, rms@gnu.org, monnier@iro.umontreal.ca To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 23 14:48:45 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 1OnWSB-0000NM-7E for ged-emacs-devel@m.gmane.org; Mon, 23 Aug 2010 14:48:43 +0200 Original-Received: from localhost ([127.0.0.1]:60335 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnWSA-0000N6-Ot for ged-emacs-devel@m.gmane.org; Mon, 23 Aug 2010 08:48:42 -0400 Original-Received: from [140.186.70.92] (port=53485 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnWS1-0008OA-0T for emacs-devel@gnu.org; Mon, 23 Aug 2010 08:48:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OnWL9-000183-Js for emacs-devel@gnu.org; Mon, 23 Aug 2010 08:41:28 -0400 Original-Received: from sun61.bham.ac.uk ([147.188.128.150]:50979) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OnWL9-00017D-Fi; Mon, 23 Aug 2010 08:41:27 -0400 Original-Received: from [147.188.128.127] (helo=bham.ac.uk) by sun61.bham.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1OnWKw-00047U-PI; Mon, 23 Aug 2010 13:41:14 +0100 Original-Received: from mx1.cs.bham.ac.uk ([147.188.192.53]) by bham.ac.uk with esmtp (Exim 4.43) id 1OnWKw-0004kp-FP; Mon, 23 Aug 2010 13:41:14 +0100 Original-Received: from acws-0068.cs.bham.ac.uk ([147.188.194.56]) by mx1.cs.bham.ac.uk with esmtp (Exim 4.51) id 1OnWKw-0001zv-HH; Mon, 23 Aug 2010 13:41:14 +0100 In-Reply-To: <878w3x7h8u.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM 8.1.92a under 22.2.1 (i386-mingw-nt5.1.2600) X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) 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:129077 Archived-At: Stephen J. Turnbull writes: > This is not true in general. In particular, the workflow suggested in > BzrForEmacsDevs can produce a "clean history"[1] without rebase, > although it may require remerging branches before pushing because of > the race condition. Yes, the current workflow does achieve clean history, but at the cost of removing any gestation period for fixes that the developers might want. I am surprised that many emacs developers are ok with it, but my own experience is that a few days of testing through daily use is necessary for me to develop confidence in some of my fixes. I would feel very exposed if I can't commit fixes to my branch without publishing them at the same time. > > Bazaar's solution is to provide merge, which lumps each batch of > > fixes together into a subhistory without concern for any logical > > coherence among the changes. > > That is not a problem of merge. All VCSes provide merge. No, I don't mean to say that merge itself is a problem. But, Bazaar's recommendation to use merge *instead of* rebase is a problem. Bazaar developers do seem to understand that merges doesn't give you a clean history (at least in Bazaar's way of presenting history), but they underrate its importance. I am actually happy with Bazaar's presentation of history. A straightline history is good for doing bisection when you need to. The practice of hiding merge histories from the top-level is also nice for ignoring unnecessary detail. Moreover, I think that even normal merged branches would benefit from rebasing. Otherwise, they involve a backwards time travel for the initial commit, which is confusing during review and even worse when you have to bisect for a change later. Maybe I am one of those "users coming from central VCS tools with poor merge tracking". But I don't see the new ways being necessarily superior. Cheers, Uday PS I am trying to keep this part of the thread focused so that Richard has a coherent story to deal with.