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: Mon, 23 Aug 2010 19:31:13 +0900 Message-ID: <878w3x7h8u.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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1282560404 24253 80.91.229.12 (23 Aug 2010 10:46:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 23 Aug 2010 10:46:44 +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 Mon Aug 23 12:46:41 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 1OnUXx-0003Qk-Kw for ged-emacs-devel@m.gmane.org; Mon, 23 Aug 2010 12:46:33 +0200 Original-Received: from localhost ([127.0.0.1]:59269 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnUXw-0005Y2-J2 for ged-emacs-devel@m.gmane.org; Mon, 23 Aug 2010 06:46:32 -0400 Original-Received: from [140.186.70.92] (port=58801 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OnUMU-0000Ki-Q6 for emacs-devel@gnu.org; Mon, 23 Aug 2010 06:34:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OnUMP-0006RN-8E for emacs-devel@gnu.org; Mon, 23 Aug 2010 06:34:42 -0400 Original-Received: from imss12.cc.tsukuba.ac.jp ([130.158.254.161]:45028) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OnUMO-0006Qm-OR; Mon, 23 Aug 2010 06:34:37 -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 AC296F4003; Mon, 23 Aug 2010 19:34:32 +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 937C5F4002; Mon, 23 Aug 2010 19:34:32 +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 87EB13FA0239; Mon, 23 Aug 2010 19:34:32 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 7EC82138845; Mon, 23 Aug 2010 19:31:13 +0900 (JST) In-Reply-To: <19570.10774.921000.853692@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:129070 Archived-At: Uday S Reddy writes: > On the other hand, distributed maintenance with a clean management > of history necessarily involves rebase. 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. Other alternatives include the pull workflow (ie, synchronization by the maintainers -- you can quibble about whether that's "really distributed", if you like, and I sympathize, but it is an option for a project), and an automated patch queue as used by the Bazaar project itself. > 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. It is a problem of the workflow and a matter of taste. Specifically, whether you care if even single commits (off mainline) are "covered" by a merge commit (on mainline). The Bazaar developers consider this a natural consequence of distributed development, and have adapted the log command to normally display only the mainline. (git and Mercurial have options to do this, or to display only merge commits, which has a similar effect.) There remains a small problem of coming up with an appropriate log message for the merge commit, but in the specific case of a single commit, you just copy the commit message into the merge log message. Some people consider such a history unsightly, and strongly prefer to rebase. But this is a matter of taste. > In the absence of rebase, the Emacs developers are forced to > synchronize with the mainline for each commit they want to do. This is only true if you insist that every commit (or every commit on mainline) in the public repo be tested. But in that case, rebase doesn't save you any synchronization compared to non-rebase. There is are at least two alternatives to rebase. The first is to use multiple workspaces, one per task, even trivial tasks. The second is to use bzr send for each logical changeset, save the bundles to disk, and then merge them one after another. If it is acceptable for the mainline to be temporarily untested, then the developer can test each commit after merging and pushing. Then of course they need to fix any problems discovered in a timely fashion. An alternative is that only the result of the last merge must pass the tests; then it's reasonable to test before pushing (although not from "make bootstrap" probably). > It would be best if they provide rebase and provide sufficient > warning, and leave it to the project managers to use them wisely. If a project is going to use rebase, git is *strongly* recommended, as it not only provides rebase, but several other features for creating "nice" histories such as filter-branch. Footnotes: [1] AIUI in Emacs practice a "clean history" means that each conceptual change, whether it is a single typo fix or integration of a new garbage collector or internal character coding, is represented by one commit on the mainline. A large feature like a new garbage collector might involve many commits on a branch, however.