From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: bzr repository ready? Date: Mon, 23 Nov 2009 16:19:27 -0600 Message-ID: <87zl6crij4.fsf@red-bean.com> 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> Reply-To: Karl Fogel NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1259014793 28599 80.91.229.12 (23 Nov 2009 22:19:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Nov 2009 22:19:53 +0000 (UTC) Cc: 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 Mon Nov 23 23:19:45 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 1NChG3-0005ep-47 for ged-emacs-devel@m.gmane.org; Mon, 23 Nov 2009 23:19:43 +0100 Original-Received: from localhost ([127.0.0.1]:34241 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NChG2-00057I-Hc for ged-emacs-devel@m.gmane.org; Mon, 23 Nov 2009 17:19:42 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NChFw-000566-IZ for emacs-devel@gnu.org; Mon, 23 Nov 2009 17:19:36 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NChFs-000523-Im for emacs-devel@gnu.org; Mon, 23 Nov 2009 17:19:36 -0500 Original-Received: from [199.232.76.173] (port=60221 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NChFs-00051r-Bx for emacs-devel@gnu.org; Mon, 23 Nov 2009 17:19:32 -0500 Original-Received: from sanpietro.red-bean.com ([66.146.206.141]:57434) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NChFq-0007Bu-0P; Mon, 23 Nov 2009 17:19:30 -0500 Original-Received: from localhost ([127.0.0.1]:49276 helo=kfogel-work ident=kfogel) by sanpietro.red-bean.com with esmtp (Exim 4.69) (envelope-from ) id 1NChFo-00062J-HG; Mon, 23 Nov 2009 16:19:28 -0600 In-Reply-To: (Richard Stallman's message of "Mon, 23 Nov 2009 15:38:37 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) 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:117642 Archived-At: Richard Stallman writes: > > They are not equivalent. The ChangeLog files are included in the > > checkout, so you can read them even when you are offline (which is > > nearly all the time, for me). `bzr log' requires contact with the > > repository. > > Yes, but the repository is local too! > > Maybe I misunderstood something. I thought the idea was to make > a local checkout from a remote repository. Are you saying people > should always copy the whole repository first? Because I don't know how experienced you are with Bazaar yet, I don't know if you're using the word "repository" in the CVS sense or in the Bazaar sense, above. The two meanings are very different. What I meant when I said "the repository is local too" is that history is local, and that therefore you can read it while offline (thus you can generate ChangeLog information while offline). By the way, I agree that we should not switch our ChangeLog practices when we switch version control systems -- the "change one variable at a time" rule is good. So this is just informational; I'm not advocating that we stop keeping ChangeLog files the moment we switch to Bazaar. In Bazaar, copying "the whole repository" is easy, and costs about the same as copying just one branch, but it doesn't mean anything special. Whether or not you copy the entire repository, you will still have full historical data for each branch you have locally, by default. That's the important thing, whereas copying "the repository" is mainly an optimization, and does not have the same implications for local access to historical data that it would in CVS. Here's an example of creating an empty shared repository locally, pulling one branch of upstream master Emacs into it, then cheaply fetching another branch into the repository later: $ bzr init-repo emacs-shared-repository $ cd emacs-shared-repository $ bzr branch URL_TO_UPSTREAM_EMACS_TRUNK ### This will take a while, because it's the first fetch ### of a great many revisions. $ bzr branch URL_TO_UPSTREAM_EMACS_SOME_OTHER_BRANCH ### This won't take long at all, because most of the revisions are ### already present locally in the shared repository, thanks to the ### first branch -- bzr won't pull that data across the wire twice. Of course, many people just save time by just copying the entire shared repository at once; that takes about as long as the initial branching of trunk would have in the example above. This is what I did to fetch the most recent test conversion of Emacs, for example: $ scp -r kfogel@bzr.savannah.gnu.org:/srv/bzr/emacs emacs-bzr-repository Now I have _all_ the branches locally, as if I had done 'bzr branch' to get them. In my earlier example, the "bzr init-repo ..." step above was optional. The commands $ bzr branch URL_TO_UPSTREAM_EMACS_TRUNK and $ bzr branch URL_TO_UPSTREAM_EMACS_SOME_OTHER_BRANCH would still work even without a repository, it's just that a) the second command would pull some data over the wire that the first command had already pulled, and b) the two branches wouldn't share storage on local disk, which could add up if you have keep lots of branches locally. I hope this helps. -Karl