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 repository ready? Date: Fri, 27 Nov 2009 18:14:13 +0900 Message-ID: <87ws1cqqhm.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87einvxy9c.fsf@red-bean.com> <20091118230952.GB908@muc.de> <87my2jw05z.fsf@red-bean.com> <83skc9pbf7.fsf@gnu.org> <87iqd5vw5n.fsf@red-bean.com> <877htl53tc.fsf@telefonica.net> <87ws1ku7zd.fsf@red-bean.com> <87hbso4s13.fsf@telefonica.net> <83aaygoy90.fsf@gnu.org> <87vdh36d48.fsf@telefonica.net> <831vjrptha.fsf@gnu.org> <87einr63b6.fsf@telefonica.net> <83y6lzo9e7.fsf@gnu.org> <871vjr750o.fsf@uwakimon.sk.tsukuba.ac.jp> <83tywnnq34.fsf@gnu.org> <873a475bsr.fsf@telefonica.net> <87ocmu7x9c.fsf@red-bean.com> <87zl6crij4.fsf@red-bean.com> <87fx82856l.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1259312938 30147 80.91.229.12 (27 Nov 2009 09:08:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Nov 2009 09:08:58 +0000 (UTC) Cc: kfogel@red-bean.com, ofv@wanadoo.es, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 27 10:08:51 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 1NDwos-0002Sy-9e for ged-emacs-devel@m.gmane.org; Fri, 27 Nov 2009 10:08:50 +0100 Original-Received: from localhost ([127.0.0.1]:41584 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NDwor-00047z-CU for ged-emacs-devel@m.gmane.org; Fri, 27 Nov 2009 04:08:49 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NDwol-00047p-Lk for emacs-devel@gnu.org; Fri, 27 Nov 2009 04:08:43 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NDwoh-000446-AS for emacs-devel@gnu.org; Fri, 27 Nov 2009 04:08:43 -0500 Original-Received: from [199.232.76.173] (port=55605 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NDwoh-000443-19 for emacs-devel@gnu.org; Fri, 27 Nov 2009 04:08:39 -0500 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:36162) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NDwob-0004ZL-W4; Fri, 27 Nov 2009 04:08:34 -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 0203E8214; Fri, 27 Nov 2009 18:08:32 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 6C63A1A2907; Fri, 27 Nov 2009 18:14:13 +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:117857 Archived-At: Richard Stallman writes: > That's correct. There is a better way, however, which is to use > a stacked branch. Stacked branches > > I don't think I have seen the term "stacked branch" before. Is it a > different term for something that has been discussed recently, > or is it something substantively different? IIRC, it's a different concept; stacked branches are relatively new. They were developed for use on project hosts like Launchpad[1], where they can save a huge amount of space for projects with many branches. There are two dimensions to be considered here. Terminological note: in this post, by "checkout" I mean a "lightweight checkout directly from the upstream master branch". A "committer" is a "maintainer or other person allowed to send changes directly to the upstream master branch". The first is "does plain 'bzr commit' commit to a local repository, to the parent (typically remote) repository, or to both?" A normal branch commits to the local repository, a checkout to the remote repository, and a bound branch to both. This means that a normal branch diverges from its parent branch immediately, a checkout cannot diverge, and a bound branch does not diverge unless the user takes some exceptional action. A *stacked branch*, like a (normal) branch, commits to the local repository. The second is "how much of the version history (file content) is maintained locally?" In a branch, full history of all versions that are ancestor to any version in the branch is kept locally. This is also true of a bound branch. In a checkout, no history at all is kept locally. A *stacked branch* is different from either: its history is distributed between the local repository and the remote. History *before* the branch point is kept in the remote repository, while *new* history is kept locally. ("New history" definitely includes merges from 3rd party branches and new commits, and IIRC also includes updates from the parent branch). A summary table is attached at the bottom. Aside from small additional space savings, for committers the advantage of a checkout over a stacked branch is that all of her commits are immediately reflected in the upstream master, saving her the effort of typing "bzr push". The disadvantage is that all of her commits are immediately reflected in the upstream master, costing her the effort of managing the changes by hand while improving and testing them, because she can't commit until the patch is "good". For non-committer hackers, the checkout is an all-around loss compared to the stacked branch. They cannot commit at all in the checkout. In return for this handicap, they can save a small amount of space. For non-hackers (ie, beta testers) the checkout saves a small amount of space at no cost since there's no need to commit. I still advocate use of stacked branches here, in hope that someday soon they will experience a sudden urge to commit. \ local history \ content Full Truncated None commit \ target +-------------------+---------------+------------+ | (normal) | stacked | | Local | branch | branch | | +-------------------+---------------+------------+ Remote | | | checkout | +-------------------+---------------+------------+ Both | bound | | | | branch | | | +-------------------+---------------+------------+ Footnotes: [1] I write "Launchpad" because this refers specifically to Launchpad's feature of giving each developer a personal shared repository for her "sandbox" branches. If the "sandbox" branches are instead kept in the main shared repository, then there will be no additional space savings from making them stacked branches. I'm not familiar with Savannah's architecture.