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: bzr workflow Date: Wed, 13 Jan 2010 13:02:37 +0900 Message-ID: <877hrm3b4y.fsf@uwakimon.sk.tsukuba.ac.jp> References: <4B4B93AB.3030903@gnu.org> <87skac1fy7.fsf@telefonica.net> <4B4C28F6.9000209@swipnet.se> <87ockz1ztm.fsf@telefonica.net> <4B4C4360.2040707@swipnet.se> <87fx6a3fyn.fsf@uwakimon.sk.tsukuba.ac.jp> <87r5puspr5.fsf@red-bean.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1263354878 17926 80.91.229.12 (13 Jan 2010 03:54:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Jan 2010 03:54:38 +0000 (UTC) Cc: =?iso-8859-1?Q?=D3scar?= Fuentes , Juanma Barranquero , Jan =?iso-8859-1?Q?Dj=E4rv?= , emacs-devel@gnu.org To: Karl Fogel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 13 04:54:30 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.50) id 1NUuJR-0006Hq-D6 for ged-emacs-devel@m.gmane.org; Wed, 13 Jan 2010 04:54:29 +0100 Original-Received: from localhost ([127.0.0.1]:42145 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NUuJS-00054H-7M for ged-emacs-devel@m.gmane.org; Tue, 12 Jan 2010 22:54:30 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NUuJ4-0004tv-2C for emacs-devel@gnu.org; Tue, 12 Jan 2010 22:54:06 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NUuIz-0004q1-6r for emacs-devel@gnu.org; Tue, 12 Jan 2010 22:54:05 -0500 Original-Received: from [199.232.76.173] (port=59796 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NUuIz-0004pr-0D for emacs-devel@gnu.org; Tue, 12 Jan 2010 22:54:01 -0500 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:45967) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NUuIy-0008Hy-De for emacs-devel@gnu.org; Tue, 12 Jan 2010 22:54:00 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id B0E531535A8; Wed, 13 Jan 2010 12:53:55 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 4D24A1A2C00; Wed, 13 Jan 2010 13:02:37 +0900 (JST) In-Reply-To: <87r5puspr5.fsf@red-bean.com> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" 1444e28f1a3d XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by monty-python.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:119893 Archived-At: Karl Fogel writes: > But at this point, I think we could update the BzrForEmacsDevs doc to > recommend just doing trivial mods in trunk and committing directly from > there. Heck, that's what I'm doing with really simple stuff. > > Can anyone think of any gotchas? Particularly gotchas that would lead > to people on this list having to provide more support not less? :-) No. I just really dislike that workflow, personally. (I accumulate typo fixes and the like separately -- what's the rush? -- and don't trust even the simplest code change to be correct without testing, at least a compile, link, re-byte-compile, run test suite -- so my quickfixes are batched, too.) But that's a personal bias that I was aware of, and I hope I mostly accounted for. What consciously bothered me was experience with Mercurial. In Mercurial, commit-to-trunk leads to a very confusing DAG as myriads of no-see-um branches get created, often in parallel, then very quickly merged. Unfortunately, they are very visible in the logs and in the hgk DAG viewer (they're called "merge turds", which is quite apt), and make use of hg diff confusing, too. But in Bazaar with trunk bound to the public repo, that won't happen. I didn't realize how powerful that technique would be. I still don't like it myself, but now I have convinced myself that it won't cause any issues for other developers. So I do not oppose including it in BzrForEmacsDevs.