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: Wed, 25 Aug 2010 00:54:36 +0900 Message-ID: <87k4ng57lv.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> <87zkwc5xnr.fsf@uwakimon.sk.tsukuba.ac.jp> <19571.53679.382000.560086@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 1282665500 17905 80.91.229.12 (24 Aug 2010 15:58:20 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 24 Aug 2010 15:58:20 +0000 (UTC) Cc: emacs-devel@gnu.org, rms@gnu.org, monnier@iro.umontreal.ca To: Uday S Reddy Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 24 17:58:18 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 1OnvtC-0006Ij-2q for ged-emacs-devel@m.gmane.org; Tue, 24 Aug 2010 17:58:18 +0200 Original-Received: from localhost ([127.0.0.1]:44228 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnvtB-0007Fu-CA for ged-emacs-devel@m.gmane.org; Tue, 24 Aug 2010 11:58:17 -0400 Original-Received: from [140.186.70.92] (port=37224 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Onvt4-0007Fc-U5 for emacs-devel@gnu.org; Tue, 24 Aug 2010 11:58:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Onvt3-00069e-CY for emacs-devel@gnu.org; Tue, 24 Aug 2010 11:58:10 -0400 Original-Received: from imss12.cc.tsukuba.ac.jp ([130.158.254.161]:39891) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Onvt2-00069I-Oy; Tue, 24 Aug 2010 11:58:09 -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 866F5F4003; Wed, 25 Aug 2010 00:58:05 +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 77737F4002; Wed, 25 Aug 2010 00:58:05 +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 75CE93FA0251; Wed, 25 Aug 2010 00:58:05 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 42FBF1A47B8; Wed, 25 Aug 2010 00:54:36 +0900 (JST) In-Reply-To: <19571.53679.382000.560086@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:129150 Archived-At: Uday S Reddy writes: > > 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. Unfortunately, it's not. YMMV, but some people do value the information that is lost by rebasing. I suspect that most Emacs people won't care, though, and will prefer the more easily reviewed rebased branches. > 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. You just invented "Darcs". > http://softwareswirl.blogspot.com/2009/04/truce-in-merge-vs-rebase-war.html Note that Haggerty is also basically trying to invent Darcs, but doesn't quite get there. It's also very similar to Robert Collins' loom plugin for bzr. The idea of loom is to allow flexible traversal of such complex DAGs during development so that patches can be applied to the right "thread" of the loom, then propagated "upward" to the current version automatically.