From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David De La Harpe Golden Newsgroups: gmane.emacs.devel Subject: Re: bzr repository ready? Date: Wed, 25 Nov 2009 22:26:14 +0000 Message-ID: <4B0DAF06.30308@harpegolden.net> 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=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1259188149 13650 80.91.229.12 (25 Nov 2009 22:29:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Nov 2009 22:29:09 +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 Wed Nov 25 23:29:01 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 1NDQM8-0007re-MD for ged-emacs-devel@m.gmane.org; Wed, 25 Nov 2009 23:29:00 +0100 Original-Received: from localhost ([127.0.0.1]:40872 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NDQM8-0007t4-7j for ged-emacs-devel@m.gmane.org; Wed, 25 Nov 2009 17:29:00 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NDQJf-0005WQ-Mi for emacs-devel@gnu.org; Wed, 25 Nov 2009 17:26:27 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NDQJa-0005Rj-P6 for emacs-devel@gnu.org; Wed, 25 Nov 2009 17:26:27 -0500 Original-Received: from [199.232.76.173] (port=37550 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NDQJa-0005RZ-Ip for emacs-devel@gnu.org; Wed, 25 Nov 2009 17:26:22 -0500 Original-Received: from harpegolden.net ([65.99.215.13]:51414) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NDQJX-0008OD-EP; Wed, 25 Nov 2009 17:26:19 -0500 Original-Received: from [87.198.54.207] (87-198-54-207.ptr.magnet.ie [87.198.54.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "David De La Harpe Golden", Issuer "David De La Harpe Golden Personal CA rev 3" (verified OK)) by harpegolden.net (Postfix) with ESMTP id A18E9828A; Wed, 25 Nov 2009 22:26:16 +0000 (GMT) User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) In-Reply-To: X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:117782 Archived-At: > We are failing to communicate I know rather less than Karl about bzr, but I'm one of the ones who would be using lightweight checkouts from a local repository, so I'll have a shot: > I'm asking about how to use lightweight checkouts. Someone > recommended them for people not writing lots of changes. > > When you make a lightweight checkout, do you have to first make a > local repository and get the branch into it? Have to? No. Can you do that if you want to? Yes. Why would you want to? See *** below. > Or can you make a lightweight checkout straight from > the remote repository? Yes. Though that's then similar to using a non-distributed VCS - a better one than CVS, but still, with usual non-distributed VCS disadvantages associated with needing to be able to talk to the remote "repository" (there's a terminological issue here as bzr is "branch centric"). > I got the impression that the lightweight checkout was recommended > because it avoids the need to make a local repository. That is a reason to make a lightweight checkout from a remote repository alright - People not writing lots of changes might use such a lightweight checkout from a remote repository as it avoids grabbing the whole branch with full historical data (a couple of hundred megs for emacs, and also doing it with bzr-over-http is slower that one would expect even given that size for whatever reason) > 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? > *** The issue of lightweight checkouts from a _local_ repository arose in the case of emulating the git sense of branches (which are not materialized as subdirectories in the filesystem). To pretend bzr is git in this respect (there are other respects in which they differ), you can make a local repository (multiple bzr branches using the same storage) configured not to populate the branch directories with actual working copies of files ("--no-trees") and branch the branches you want into it. Then you do a lightweight checkout of a branch to single working directory, then you switch that single working directory between lightweight checkouts of your different branches with the "bzr switch" command. This means you have lots less branch directories populated with files, assuming you have multiple branches. A cited disadvantage of "branches are subdirectories" was the need to separately "make bootstrap" each branch separately. If you're switching a single working directory between checkouts of branches, you can "get away with" not bootstrapping so much, something like switching cvs branches with (IIRC) "cvs update -r". > Do you have to make a checkout from the branch in order to get > source files you can use? Only if you've made a branch with no working copies of source files with the --no-trees option because you're emulating git style as above.