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 08:58:14 +0100 Message-ID: <19570.10774.921000.853692@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> 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 1282550342 18285 80.91.229.12 (23 Aug 2010 07:59:02 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 23 Aug 2010 07:59:02 +0000 (UTC) Cc: Uday S Reddy , monnier@iro.umontreal.ca, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 23 09:58:59 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 1OnRvk-0004Pi-NV for ged-emacs-devel@m.gmane.org; Mon, 23 Aug 2010 09:58:57 +0200 Original-Received: from localhost ([127.0.0.1]:49763 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnRvk-0001ax-5M for ged-emacs-devel@m.gmane.org; Mon, 23 Aug 2010 03:58:56 -0400 Original-Received: from [140.186.70.92] (port=57790 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnRvd-0001ai-OF for emacs-devel@gnu.org; Mon, 23 Aug 2010 03:58:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OnRvc-0001nt-FX for emacs-devel@gnu.org; Mon, 23 Aug 2010 03:58:49 -0400 Original-Received: from sun60.bham.ac.uk ([147.188.128.137]:48528) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OnRvc-0001nV-AQ; Mon, 23 Aug 2010 03:58:48 -0400 Original-Received: from [147.188.128.127] (helo=bham.ac.uk) by sun60.bham.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1OnRvZ-0000CM-Ox; Mon, 23 Aug 2010 08:58:45 +0100 Original-Received: from mx1.cs.bham.ac.uk ([147.188.192.53]) by bham.ac.uk with esmtp (Exim 4.43) id 1OnRvZ-0003jF-EZ; Mon, 23 Aug 2010 08:58:45 +0100 Original-Received: from gromit.cs.bham.ac.uk ([147.188.193.16] helo=MARUTI.cs.bham.ac.uk) by mx1.cs.bham.ac.uk with esmtp (Exim 4.51) id 1OnRvZ-00080p-9B; Mon, 23 Aug 2010 08:58:45 +0100 In-Reply-To: X-Mailer: VM 8.1.92a under 23.2.1 [EmacsW32 Version 1.58 2010-08-02] (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:129065 Archived-At: Richard Stallman writes: > I can try -- but first I need a clear and self-contained description > of the problem. Is the problem solely one of occasional unpredictable > failures? Well, first of all, Bazaar itself does not have rebase. Somebody added a plug-in and this has been distributed with Bazaar. My version of Bazaar (2.1.0) came bundled with rebase 0.5.5. The version number below 1 doesn't inspire much confidence. And, it has been reported that it silently drops merges in the branch that is being rebased. A really serious bug, if you ask me. I don't know what other bugs might be lurking. Other people that have tried it can perhaps share their experience. There are reports that the Bazaar team doesn't regard rebase as a good technique at all. So, it is unlikely that they will provide any better support for it. On the other hand, distributed maintenance with a clean management of history necessarily involves rebase. If 10 people work on bug fixes independently, we need to be able to arrange those fixes in some linear order when the fixes come back. 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. Such lumping is discouraged by Emacs development team, understably, because, if the lumps don't have any logical coherence, it is as if they don't exist at all. Whoever is looking through the history will have to look through every lump to find what he/she is looking for. In the absence of rebase, the Emacs developers are forced to synchronize with the mainline for each commit they want to do. This wastes time. It can also be unreliable in the long run, because developers tend to think of the synchronization steps as being more or less automatic rather than logical changes that they really are, which involve review and testing. If Bazaar is going to be the favoured VCS for all gnu projects because of its membership in the gnu family, then it has to think about what the rest of gnu needs. I understand that they want to provide safe solutions that novices can use, but they are also tying the hands of experienced developers from using the best possible solutions. It would be best if they provide rebase and provide sufficient warning, and leave it to the project managers to use them wisely. Cheers, Uday