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: Thu, 26 Nov 2009 10:07:14 +0900 Message-ID: <87fx82856l.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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1259197311 5637 80.91.229.12 (26 Nov 2009 01:01:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 26 Nov 2009 01:01:51 +0000 (UTC) Cc: Karl Fogel , 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 Thu Nov 26 02:01:43 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 1NDSjs-0006ln-FF for ged-emacs-devel@m.gmane.org; Thu, 26 Nov 2009 02:01:40 +0100 Original-Received: from localhost ([127.0.0.1]:42065 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NDSjr-0004zn-RU for ged-emacs-devel@m.gmane.org; Wed, 25 Nov 2009 20:01:39 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NDSjm-0004yn-Tp for emacs-devel@gnu.org; Wed, 25 Nov 2009 20:01:34 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NDSji-0004wX-8p for emacs-devel@gnu.org; Wed, 25 Nov 2009 20:01:34 -0500 Original-Received: from [199.232.76.173] (port=58178 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NDSji-0004wU-5o for emacs-devel@gnu.org; Wed, 25 Nov 2009 20:01:30 -0500 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:58677) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NDSjc-0006qJ-L7; Wed, 25 Nov 2009 20:01:25 -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 DAD6B1535A8; Thu, 26 Nov 2009 10:01:22 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id C1ACB128BFB; Thu, 26 Nov 2009 10:07:14 +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:117796 Archived-At: Richard Stallman writes: > I'm asking about how to use lightweight checkouts. Someone > recommended them for people not writing lots of changes. They're not in the BzrForEmacsDevs document, and if they appear, I will *dis*appear and refuse to touch that document thereafter. ;-) > I got the impression that the lightweight checkout was recommended > because it avoids the need to make a local repository. That's correct. There is a better way, however, which is to use a stacked branch. Stacked branches (1) retrieve only enough history to reconstitute the requested version of the source tree, and (2) create new history locally (only locally) when "bzr commit" is invoked. This has the following purposes: (1) minimize the time and space cost of the initial branch operation, (2) allow convenient updating to new upstream versions, (3) allow people without commit privilege on Savannah to commit locally, which (4) allows them to conveniently maintain both purely local hacks, and (5) work intended for contribution back to the Emacs project. It has certain defects: (1) any operation (such as diff or log) that needs history before the initial version must go out to the upstream repo to get it. Ie, it's slow and requires a network connection. This mode of operation is recommended for beta testers, since they are likely to start by just updating once in a while, but it imposes minimum cost if they alter the sources: just commit the change (locally). It is *severely* deprecated for core developers. > The questions I've asked are based on that understanding. The > answers I get seem to suggest the contrary, These are experienced users explaining how they would use lightweight checkouts to their own advantage. Lightweight checkouts are neither needed nor recommended for novice bzr users. (Most of the people describing how they would use checkouts have said the same thing.) > In other words, after doing > > bzr branch URL_TO_UPSTREAM_EMACS_TRUNK > > why not just go ahead and edit the files in the directory > for that branch? There is no reason not to do that, except if you have commit privileges in the upstream repository. If you are going to push directly to the upstream repository, then the roundabout method: cd WORKSPACE emacs bzr commit cd MIRROR bzr merge WORKSPACE bzr push produces a much nicer "bzr log" output. That is, the default view in the upstream branch (and its mirrors) shows only the merge commits. Each merge log describes the whole task (which might be something as big as the emacs-unicode development and merge) in *one* log. You can also request a detailed output with "bzr log -n0", which lists the entire history of a branch leading up the the merge. This may not sound like much to you, but bzr fans consider this a really important feature. > Is that true? Once you do that command above, what is the state? > What can you actually DO with the branch at that point? After "bzr branch URL_TO_UPSTREAM_EMACS_TRUNK emacs-work" *outside* of a shared repo, you have in the emacs-work directory (1) a full source tree as you would get with a CVS checkout, plus (2) a .bzr directory containing branch configuration metadata (eg, project-wide bzr defaults and the source URL), plus (3) a .bzr/repository directory containing the entire history of the upstream branch, including the full history of any branches merged into the upstream branch up to the point of the merge. You may now unplug your computer from the Internet, and go to work, performing all the operations that one can do with a single Bazaar branch: commit, diff, log, branch, checkout, status (and some others). Since you can commit, of course you can edit the files and manage those changes with bzr. You cannot push, pull, or update from the parent, of course (you just pulled the plug!) If you do "bzr branch URL_TO_UPSTREAM_EMACS_TRUNK emacs-work" *inside* of shared repository *configured as recommended in the wiki*, you have (1) a .bzr directory containing branch configuration metadata (eg, project-wide bzr defaults and the source URL), plus (2) a ../.bzr/repository directory containing the entire history of the upstream branch, including the full history of any branches merged into the upstream branch up to the point of the merge. Note the ".." in (2). (In fact it could be more than one level of parent, but that's not something that novice users need to do.) To summarize: > Do you have to make a checkout from the branch in order to get > source files you can use? If you do "bzr branch" outside of a shared repository, no. You're ready to go, but you should not push directly to the upstream branch. If you do it inside of a shared repository, you need to do something to reconstitute the source tree. I recommend the procedure described in the wiki, *not* a checkout, however. In fact, I do not know how the proponents of checkouts propose to preserve "nice" history with the workflows they describe. It's probably possible, but I don't know a straightforward recipe that's less complex than the wiki recommendation. If somebody does, they should feel free to edit the wiki.