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: Workflow to accumulate individual changes? Date: Fri, 01 Jan 2010 21:33:41 +0900 Message-ID: <87bphengwq.fsf@uwakimon.sk.tsukuba.ac.jp> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1262348632 16219 80.91.229.12 (1 Jan 2010 12:23:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 1 Jan 2010 12:23:52 +0000 (UTC) Cc: Emacs developers To: Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 01 13:23:45 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 1NQgXg-00075J-Pf for ged-emacs-devel@m.gmane.org; Fri, 01 Jan 2010 13:23:45 +0100 Original-Received: from localhost ([127.0.0.1]:39123 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQgXg-0005i2-UC for ged-emacs-devel@m.gmane.org; Fri, 01 Jan 2010 07:23:44 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NQgXb-0005hx-T6 for emacs-devel@gnu.org; Fri, 01 Jan 2010 07:23:39 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NQgXW-0005hN-B6 for emacs-devel@gnu.org; Fri, 01 Jan 2010 07:23:38 -0500 Original-Received: from [199.232.76.173] (port=48864 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQgXW-0005hK-7S for emacs-devel@gnu.org; Fri, 01 Jan 2010 07:23:34 -0500 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:50741) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NQgXV-0007b2-LF for emacs-devel@gnu.org; Fri, 01 Jan 2010 07:23:34 -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 A5E2A1535A8; Fri, 1 Jan 2010 21:23:31 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id A4E481A33D7; Fri, 1 Jan 2010 21:33:41 +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:119200 Archived-At: Juanma Barranquero writes: > 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. I don't understand what you're concerned about (yes, I've seen the followup which includes the footnote). If you follow the procedure for creating a shared repository (described in BzrForEmacsDevs, among other places), then all branches under the shared repository directory share storage, and creating a branch is very cheap (ie, the cost of copying the tree, which is small since you can use hardlinks).[1] I would think this would be fine for anything requiring more than one commit. In any case, I think it would be worth trying, you might find it's perfectly satisfactory. You can make this slightly cheaper by using "checkout --lightweight" (but the main cost is still creating the tree). If you have a series of one-commit changes, the cheapest way to do it would be with rebase. (N.B. I can't help you with "bzr rebase" itself, I've never used it.) The idea would be to put each commit in the same branch. You will almost certainly have exactly one conflict per ChangeLog you touch, but after that your commits will take place on top of the previous one, and should be fine (at least, I think bzr is smart enough not to conflict again). > Once the trunk is open again, what would be the procedure to install > the changes? If you follow any of the above, you would just follow the usual procedure for installing as described in BzrForEmacsDevs. > Obviously not "bzr merge ../post-23.2", because that would create a > single [merge] commit. Yup, see attached script[2]. I don't have a plugin, but I have a script that you can use to simulate the workflow you propose (if you're on Windows you'll need to .BATify or use Cygwin). Tested and works on Gentoo GNU/Linux. Two workflows I tried unsuccessfully are also documented there for posterity. Footnotes: [1] You may need to tune the branch command to use hardlinks instead of copies. [2] # set up a trunk mirror as usual # test code: uncomment next statement to test TESTP=t if test -n "$TESTP"; then newfile () { echo $1 > $1; bzr add $1; } addlog () { echo $1 > .tmp0; cat .tmp0 ChangeLog > .tmp1; mv .tmp1 ChangeLog; } cd /tmp mkdir shared-repo cd shared-repo bzr init-repo mkdir remote-trunk cd remote-trunk bzr init newfile ChangeLog newfile foo bzr commit -m "add foo" cd .. bzr checkout remote-trunk trunk fi # set up your post 23.2 branch bzr branch trunk post-23.2 cd post-23.2 # hack ... commit ... hack ... commit ... until trunk open # more test code if test -n "$TESTP"; then newfile bar addlog 'add bar' bzr commit -m 'add bar' newfile baz addlog 'add baz' bzr commit -m 'add baz' # simulate concurrent work cd ../remote-trunk newfile quux addlog 'add quux' bzr commit -m 'add quux' fi # here's the install procedure itself cd ../trunk bzr update # trunk is now up-to-date cd ../post-23.2 # durn, in testing the update fails, branches have diverged # bzr update # durn, in testing the merge --pull succeeds but leaves you with the # remote changes at the top bzr merge --pull # what I hoped for but doesn't actually work (it creates a true merge # rather than a fast forward) # cd ../trunk # bzr pull ../post-23.2