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 11:18:24 +0900 Message-ID: <87fx6a3fyn.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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1263348609 2987 80.91.229.12 (13 Jan 2010 02:10:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 13 Jan 2010 02:10:09 +0000 (UTC) Cc: =?iso-8859-1?Q?=D3scar?= Fuentes , Jan =?iso-8859-1?Q?Dj=E4rv?= , emacs-devel@gnu.org To: Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 13 03:10:01 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 1NUsgK-0002YQ-EB for ged-emacs-devel@m.gmane.org; Wed, 13 Jan 2010 03:10:00 +0100 Original-Received: from localhost ([127.0.0.1]:43166 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NUsgK-0001Xs-GY for ged-emacs-devel@m.gmane.org; Tue, 12 Jan 2010 21:10:00 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NUsgF-0001Wx-Kt for emacs-devel@gnu.org; Tue, 12 Jan 2010 21:09:55 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NUsgA-0001TI-Vw for emacs-devel@gnu.org; Tue, 12 Jan 2010 21:09:54 -0500 Original-Received: from [199.232.76.173] (port=49687 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NUsgA-0001TB-NP for emacs-devel@gnu.org; Tue, 12 Jan 2010 21:09:50 -0500 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:39865) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NUsgA-0007Fv-7t for emacs-devel@gnu.org; Tue, 12 Jan 2010 21:09:50 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id E231E820F; Wed, 13 Jan 2010 11:09:42 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 10F4A1A2C00; Wed, 13 Jan 2010 11:18:25 +0900 (JST) In-Reply-To: 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:119887 Archived-At: Juanma Barranquero writes: > On Tue, Jan 12, 2010 at 10:39, Jan Dj=E4rv wrote: >=20 > > This can't be done in the trunk branch > > (as per the Wiki) as we don't even compile there. >=20 > FWIW, there's no intrinsic problem in building trunk; that it is not > recommended in the introductory document just means that it is added > complexity not deemed necessary for beginners, As far as I know, it's not complex one way or the other, although I have been a vpath addict for over a decade, so I have no experience. The only thing you need to be careful about is that *all* build products are in .bzrignore, and that you don't accidentally add any scratch files you personally create, since the recommended workflows do most pushing from there. FWIW, the real reason that we didn't say anything about it is that the original idea was that the trunk would be treeless, but it turns out that you can't merge a branch without a tree. (It's not impossible in theory -- eg, if the divergent changes affect different files -- but bzr won't do it.) > That said, as Eli has commented, bootstrapping is generally not *that* > painful, But this isn't about "general", it's about a workflow where "bzr merge" is considered too painful.