From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Locks on the Bzr repository Date: Tue, 24 Aug 2010 15:31:52 +0900 Message-ID: <87zkwc5xnr.fsf@uwakimon.sk.tsukuba.ac.jp> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1282631832 1004 80.91.229.12 (24 Aug 2010 06:37:12 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 24 Aug 2010 06:37:12 +0000 (UTC) Cc: rms@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Uday S Reddy Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 24 08:37:09 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 1Onn86-00059v-Et for ged-emacs-devel@m.gmane.org; Tue, 24 Aug 2010 08:37:06 +0200 Original-Received: from localhost ([127.0.0.1]:35668 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Onn85-0000GW-D8 for ged-emacs-devel@m.gmane.org; Tue, 24 Aug 2010 02:37:05 -0400 Original-Received: from [140.186.70.92] (port=36206 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Onn6U-0007wL-Nj for emacs-devel@gnu.org; Tue, 24 Aug 2010 02:35:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Onn6P-00039h-Km for emacs-devel@gnu.org; Tue, 24 Aug 2010 02:35:26 -0400 Original-Received: from imss12.cc.tsukuba.ac.jp ([130.158.254.161]:60384) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Onn6P-00039N-62; Tue, 24 Aug 2010 02:35:21 -0400 Original-Received: from imss12.cc.tsukuba.ac.jp (imss12.cc.tsukuba.ac.jp [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 49580F4003; Tue, 24 Aug 2010 15:35:18 +0900 (JST) Original-Received: from mgmt1.sk.tsukuba.ac.jp (unknown [130.158.97.223]) by imss12.cc.tsukuba.ac.jp (Postfix) with ESMTP id 305DDF4002; Tue, 24 Aug 2010 15:35:18 +0900 (JST) Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 25FEC3FA0245; Tue, 24 Aug 2010 15:35:18 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 2BF851A47B8; Tue, 24 Aug 2010 15:31:52 +0900 (JST) In-Reply-To: <19570.27753.731000.392172@gargle.gargle.HOWL> X-Mailer: VM undefined under 21.5 (beta29) "garbanzo" ed3b274cc037 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:129115 Archived-At: Uday S Reddy writes: > 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. 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. > 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 don't understand. Especially since you say you're happy with bzr's presentation of history. > 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. 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. 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. > But I don't see the new ways being necessarily superior. I'm not sure what you mean by "necessarily" superior. They are not globally superior; indeed, to take advantage of their features requires at least minimal investment in learning new patterns (even for bzr, which takes pains to provide commands to emulate "traditional" workflows), and taking substantial advantage normally requires change in workflows. In the projects I've seen make the change, there is almost always a division, with the most productive contributors (by patch or LOC count; of course there are other important measures of productivity) strongly in favor of more distributed practices and willing to make some investment, and less productive ones happy with the status quo, and opposing the "unnecessary" change.