From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Giorgos Keramidas Newsgroups: gmane.emacs.devel Subject: Re: Workflow to accumulate individual changes? Date: Thu, 31 Dec 2009 00:54:39 +0200 Message-ID: <87637of4y8.fsf@kobe.laptop> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1262213707 6849 80.91.229.12 (30 Dec 2009 22:55:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Dec 2009 22:55:07 +0000 (UTC) Cc: Emacs developers To: Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 30 23:55:00 2009 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 1NQ7RT-0003oS-Kr for ged-emacs-devel@m.gmane.org; Wed, 30 Dec 2009 23:55:00 +0100 Original-Received: from localhost ([127.0.0.1]:47734 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQ7RT-00080o-QC for ged-emacs-devel@m.gmane.org; Wed, 30 Dec 2009 17:55:00 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NQ7RM-0007yn-1Q for emacs-devel@gnu.org; Wed, 30 Dec 2009 17:54:52 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NQ7RH-0007wT-Ew for emacs-devel@gnu.org; Wed, 30 Dec 2009 17:54:51 -0500 Original-Received: from [199.232.76.173] (port=38767 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQ7RG-0007wN-Uy for emacs-devel@gnu.org; Wed, 30 Dec 2009 17:54:47 -0500 Original-Received: from poseidon.ceid.upatras.gr ([150.140.141.169]:46784) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NQ7RG-0008Mi-8Z for emacs-devel@gnu.org; Wed, 30 Dec 2009 17:54:46 -0500 Original-Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id EB89CEB48C6; Thu, 31 Dec 2009 00:54:42 +0200 (EET) Original-Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id CE1AA44FE1; Thu, 31 Dec 2009 00:54:45 +0200 (EET) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Original-Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cP3VXAaSOkeq; Thu, 31 Dec 2009 00:54:45 +0200 (EET) Original-Received: from kobe.laptop (ppp-94-64-238-171.home.otenet.gr [94.64.238.171]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 6729544FDF; Thu, 31 Dec 2009 00:54:45 +0200 (EET) Original-Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id nBUMsfmh006500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Dec 2009 00:54:41 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Original-Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id nBUMseMW006497; Thu, 31 Dec 2009 00:54:40 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) In-Reply-To: (Juanma Barranquero's message of "Wed, 30 Dec 2009 22:34:07 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (berkeley-unix) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:119080 Archived-At: On Wed, 30 Dec 2009 22:34:07 +0100, Juanma Barranquero wrote: > Let's suppose I want to create a local post-23.2 branch where I do > want to commit small changes to install on the trunk post-release. I > don't want to be forced to create a task branch for every one of them, > because they are small changes, and a new branch implies having to > bootstrap[1] anew. So I'd like to accumulate the changes into a single > branch. > > Once the trunk is open again, what would be the procedure to install > the changes? Obviously not "bzr merge ../post-23.2", because that > would create a single [merge] commit. Will I be forced to repeat "bzr > log" and "bzr merge --revision=REVID ../post-23.2" for each change? > That seems a bit cumbersome. Is there any way to simplify it? Perhaps > a plugin? Hi Juanma, If the changes are separate commits, it *may* be simple to avoid a gazillion merges (one for each small change) by using the rebase plugin of bazaar. This way instead of having a history like [1] [2] [3] / / / o --- o --- o --- o --- o --- o with 'o' revisions being trunk commits and local changes [1], [2] and [3] forking from several different ancestor changesets, you can keep your changes in a local branch like this o --- o --- o --- o --- o --- o --- [1] --- [2] --- [3] Every time you "bzr pull" from the trunk, you can re-rebase your local changesets on top of the new trunk. Without rebase, you would have to merge each one of [1], [2] and [3] separately, resulting in a final history similar to: [1] ----------------------------. / \ o --- o --- o --- o --- o --- o --- [m1] --- [m2] --- [m3] \ \ / / [2] [3] ------------ / --------' \ / `-----------------------' with one merge changeset for each local patch. This is a moderately complex history graph, that is mostly readable for three local changes, but things quickly get messy with, say, upwards of 20 local patches. The mostly linear history of rebased changesets is easier to read for local patches. At least it is for me. The good thing about keeping a local set of patches rebased to the latest version of turnk is that you can start developing the patches with revision N of the trunk: o --- o --- [N] --- [1] --- [2] then you cal pull as many times as necessary from the trunk (pull revisions marked with '*' below: o --- o --- [N] --- o --- * --- o --- o --- * --- [1] --- [2] and keep the local patches rebased until they are 'done'. When they are ready for trunk, you can simply "bzr push" them and stop rebasing the local patches. They are not part of trunk and everyone will see them. The down-sides of rebasing that I know of are: (1) You cannot publish the rebased changesets and then rebase them again. People who pulled the `old' rebase will still have it in their local branch and you cannot do anything to delete *their* local changes. (2) Rebasing modifies the history but does not necessarily leave any trace of the old state of the branch. So if you discover that you botched the rebase or one of the merges that happened *during* the rebase, you are screwed. Keeping a backup copy of the local branch *before* a rebase operation (e.g. a tarball) is always a good idea. (3) Rebasing in a bound branch is probably a bad idea. I am not sure how well the plugin will work with changes that are already pushed to the remote side of a bound branch. It is very likely that it will create a very messed up branch state both in the local and the remote side of the world. Having said that I've previously posted a, admittedly rather minimal, example of instructions for the installation and the commands of the bzr-rebase plugin at . It may be worth expanding on this if you think it would help you keep a set of local-only patches until they are ready for the public trunk. HTH, Giorgos