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: Workflow to accumulate individual changes? Date: Sat, 02 Jan 2010 12:46:30 +0900 Message-ID: <87y6khmand.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87bphengwq.fsf@uwakimon.sk.tsukuba.ac.jp> 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 1262403407 13441 80.91.229.12 (2 Jan 2010 03:36:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 Jan 2010 03:36:47 +0000 (UTC) Cc: Emacs developers To: Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 02 04:36:40 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 1NQunA-0001UW-4u for ged-emacs-devel@m.gmane.org; Sat, 02 Jan 2010 04:36:40 +0100 Original-Received: from localhost ([127.0.0.1]:53614 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQunA-0002kV-Kb for ged-emacs-devel@m.gmane.org; Fri, 01 Jan 2010 22:36:40 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NQun5-0002iD-32 for emacs-devel@gnu.org; Fri, 01 Jan 2010 22:36:35 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NQun0-0002Zn-Eh for emacs-devel@gnu.org; Fri, 01 Jan 2010 22:36:34 -0500 Original-Received: from [199.232.76.173] (port=43511 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQun0-0002ZR-61 for emacs-devel@gnu.org; Fri, 01 Jan 2010 22:36:30 -0500 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:51746) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NQumz-0007FO-Kr for emacs-devel@gnu.org; Fri, 01 Jan 2010 22:36:30 -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 8551E1535A8; Sat, 2 Jan 2010 12:36:25 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id B8D6A1A33D7; Sat, 2 Jan 2010 12:46:30 +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:119249 Archived-At: Juanma Barranquero writes: > Well, if you read the note, you know what am I concerned about: not > the time for checking out the files, but the time to get the branch in > a runnable state. On my computer, "bzr branch trunk/ test/" is ~35s, > while "make bootstrap" is ~20min. Ah, I skipped over that. The way that is often recommended to handle that is to have a test tree, which is setup as a checkout. So bzr branch trunk build-test cd build-test make bootstrap make test # if you like, but should be OK :-) for i =3D 1 2 3; do cd .. bzr branch trunk fix$i cd fix$i # hack bzr commit -m "fix$i" cd ../build-test bzr checkout ../fix$i make # Look Ma, no 'bootstrap'! make test done YMMV, and caveat hacer: I haven't used this workflow personally, nor have I tested that my command syntax is correct. > (Well, colocated branches =E0 la git would be wonderful for this > case...) Maybe someday, but AFAICS the main candidates for developing such (Aaron Bentley and Robert Collins) are putting their efforts into quilt-cum-VCS efforts ("pipelines" and "looms", respectively). Somebody like you who has a fair amount of DVCS knowledge already (I don't know how much that is exactly but I'm pretty sure from your comments that it is sufficient for this) should look at pipelines (similar to Mercurial queues, and maybe Stacked Git) and looms. Pipelines really do have a sequential nature to them, which might or might not get in the way, and AFAIK they don't yet have an mq-like guard mechanism. Looms are an original idea of Robert's and some folks I really respect love them until the fur rubs off. In particular, they can sort of be abused in a "guard"-like fashion, I think. But it will require experimentation; neither pipelines nor looms are documented up to Bazaar's usual standards. (I agree with Eli about those standards, by the way; that's why I think experimenting with these requires "sufficient DVCS background".) > > If you have a series of one-commit changes, the cheapest way to do it > > would be with rebase. >=20 > That seems to be the consensus, yes. The methods suggested above might be useful too. For one-off patches, I use mq all the time because Mercurial's support for colocated branches "should be indented 6 feet downward", at least from my relatively git-centric viewpoint. But I also use guards extensively because I often submit even one-offs for review, so it's not always the case that writing order is push order. I don't know offhand how to emulate guards in bzr.