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 15:05:35 +0100 Message-ID: <19571.53679.382000.560086@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> <19570.27753.731000.392172@gargle.gargle.HOWL> <87zkwc5xnr.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 1282658759 18510 80.91.229.12 (24 Aug 2010 14:05:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 24 Aug 2010 14:05:59 +0000 (UTC) Cc: Uday S Reddy , rms@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 24 16:05:57 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 1Onu8P-0003ah-NZ for ged-emacs-devel@m.gmane.org; Tue, 24 Aug 2010 16:05:54 +0200 Original-Received: from localhost ([127.0.0.1]:44012 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Onu8P-0007K7-4p for ged-emacs-devel@m.gmane.org; Tue, 24 Aug 2010 10:05:53 -0400 Original-Received: from [140.186.70.92] (port=60220 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Onu8G-0007JF-RU for emacs-devel@gnu.org; Tue, 24 Aug 2010 10:05:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Onu8F-0006As-Es for emacs-devel@gnu.org; Tue, 24 Aug 2010 10:05:44 -0400 Original-Received: from sun61.bham.ac.uk ([147.188.128.150]:43638) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Onu8D-0006AM-LS; Tue, 24 Aug 2010 10:05:41 -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 1Onu88-0006Aa-Nr; Tue, 24 Aug 2010 15:05:36 +0100 Original-Received: from mx1.cs.bham.ac.uk ([147.188.192.53]) by bham.ac.uk with esmtp (Exim 4.43) id 1Onu88-0000v3-Dy; Tue, 24 Aug 2010 15:05:36 +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 1Onu88-0003ee-5G; Tue, 24 Aug 2010 15:05:36 +0100 In-Reply-To: <87zkwc5xnr.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:129137 Archived-At: Stephen J. Turnbull writes: > Not at all. I'm not sure if Eli would do a "one-commit" patch in a > separate workspace, and then merge, but he's said several times now > that he uses multiple workspaces, at least for feature branches. It's > certainly possible to have a "feature branch" for a one-line patch. > So you put your change in a separate workspace and test it there. You > merge when you're happy with it. This is nicer with rebase, I admit, > but it's not impossible without it. Yes, Eli himself said that he wants simplicity, and he suffers the delays of immediate push's done by the bound branch as a result of that. I think most developers here would rather not open up task branches for small fixes. I think > There are multiple schools of thought about this. Specifically, > bisecting on > > A1 -- ... -- An > / \ > 0 1 > \ / > B1 -- ... -- Bm > > vs. bisecting on > > 0 = A1 -- ... -- An -- B1 -- ... -- Bm = 1 > > will indeed identify a particular Bi commit as the source of the > problem. However, many developers feel that understanding that A1 and > B1 were both designed in the context of commit 0 is important for > understanding the evolution of A and B. Yes, I am better able to understand this view point now as a result of this debate. Note that Bazaar's presentation of the above merge is: 0 = A1 -- ... -- An .......................1 \ / \ -- B1 -- ... -- Bm -/ and I had orignally missed the idea that B1 should be thought of really as a successor to 0 = A1. So, going from An to B1 includes first a backwards time travel (An -> A1) and going from Bm to 1 includes a fast forward (A1 -> An). Bazaar's presentation makes it appear as if B1...Bm have been rebased but, in reality, they are the original commits that are just being stuck in the middle of the mainline. If one is doing a bisection to find a problem, one would do it first on the mainline, find that the fault occurs somewhere between An and 1, and then do a second bisection on B1...Bm. If one is doing this by hand, it is quite confusing in having to deal with A1 again while looking through B1...Bm. I would ask, "A1 works ok, but what is B1 adding that is breaking things?" But, oops, B1 is doing something entirely different! > This information is lost by > the rebase. And in fact, it may be that the design of B is cleaner or > more central to future development, so that you really want to fix A, > and leave B alone. So bisecting may lead to poor selection of fixes. I think the loss of information is a myth. Information will be lost only if the VCS deliberately loses it. There is no reason why the VCS can't keep track of B1...Bm in terms of patches on A1 as well as patches on An. You can then rebase it forwards and backwards as often as you need to, to get the information you want. Rethinking the issues now, it is becoming clear to me that there are two independent, but related, issues: - Storage: You want to store a history that is accurate so that you can go back to it when you want to. - Presentation: You want to produce a rebased history for review and forensic analysis because it is easier to deal with. One might want to go back to the accurate history if the rebased history doesn't work. I notice that Stefan proposed essentially this idea in the bazaar developers list, and Michael Haggerty has a more elaborate presentation of the issues here: http://softwareswirl.blogspot.com/2009/04/truce-in-merge-vs-rebase-war.html Cheers, Uday