From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: bzr repository ready? Date: Wed, 25 Nov 2009 23:19:16 +0100 Message-ID: <87hbsifdsr.fsf@telefonica.net> References: <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=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1259187805 12505 80.91.229.12 (25 Nov 2009 22:23:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Nov 2009 22:23:25 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 25 23:23:18 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 1NDQGX-0005FW-V6 for ged-emacs-devel@m.gmane.org; Wed, 25 Nov 2009 23:23:15 +0100 Original-Received: from localhost ([127.0.0.1]:60057 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NDQGX-0003Eg-6e for ged-emacs-devel@m.gmane.org; Wed, 25 Nov 2009 17:23:13 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NDQFZ-0002pc-9z for emacs-devel@gnu.org; Wed, 25 Nov 2009 17:22:13 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NDQFT-0002m0-Tx for emacs-devel@gnu.org; Wed, 25 Nov 2009 17:22:12 -0500 Original-Received: from [199.232.76.173] (port=37447 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NDQFT-0002lr-PI for emacs-devel@gnu.org; Wed, 25 Nov 2009 17:22:07 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:59430) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NDQFT-00080A-8U for emacs-devel@gnu.org; Wed, 25 Nov 2009 17:22:07 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.50) id 1NDQFQ-0004jD-Ca for emacs-devel@gnu.org; Wed, 25 Nov 2009 23:22:04 +0100 Original-Received: from 141.red-81-38-65.dynamicip.rima-tde.net ([81.38.65.141]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 25 Nov 2009 23:22:04 +0100 Original-Received: from ofv by 141.red-81-38-65.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 25 Nov 2009 23:22:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 149 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 141.red-81-38-65.dynamicip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) Cancel-Lock: sha1:rP6KoMebqonnF/Ywn4j217uQLR0= 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:117780 Archived-At: Richard Stallman writes: [snip] > I'm asking about how to use lightweight checkouts. Someone > recommended them for people not writing lots of changes. Other than disk space savings, there is no reason for using lightweight checkouts as a means to write an occassional change. Either you misunderstood the context of the recommendation (because lightweight checkouts are widely used on some advanced setups, maybe he was talking about that) or the recommendation is not good, IMO. > When you make a lightweight checkout, do you have to first make a > local repository and get the branch into it? Not required. > Or can you make a lightweight checkout straight from the remote > repository? Yes. > I got the impression that the lightweight checkout was recommended > because it avoids the need to make a local repository. The questions > I've asked are based on that understanding. The answers I get seem to > suggest the contrary, that the lightweight checkout is made from a > local repository. You can make the lightweight from any *branch* (in bazaar, repositories are just collections of not-necessarily-related branches, used for optimizing access and storage. A branch is an independent entity: you don't need a repository for having a branch.) > But if that's true, I don't see what good the > lightweight checkout does. Why not edit the local repository's source > files directly? > > 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? You can certainly do that. Why most people don't? Because as it is so easy to clone branches and move revisions from one branch to another branch in a dVCS, what is recommended is: 1. Create a repository for taking advantage of the space savings and fast operations it provides. 2. Clone the upstream branch into your repository. 3. Keep that branch as a pristine local mirror of upstream. 4. Clone your upstream local mirror branch for creating another branch you use for hacking. >From here, there are lots of variations, with a varied degree of complexity. > The text in the wiki seems to say that you pull over a branch with > `bzr branch', and doesn't say anything else is necessary before you > use it. > > Is that true? Yes. > Once you do that command above, what is the state? You have a copy of the branch you cloned. The only thing that differentiates your new branch from the cloned one is that your new branch refers to the cloned one as its "parent". For the rest they are identical. > What can you actually DO with the branch at that point? Whatever you please. Really. > Do you have to make a checkout from the branch in order to get > source files you can use? Only if you explicitly requested from the `bzr branch' command that it shouldn't create the source files: bzr branch --no-tree URL_TO_UPSTREAM_EMACS_TRUNK ___________^^^^^^^^^ or if you created your repository (in case you are using one, which is recommended) with bzr init-repo --no-trees my-repository ______________^^^^^^^^^^ Otherwise, your newly cloned branch will have all the source files ready to be edited. Please note that the previous responde to you on this subthread was from Karl Fogel. I have a different opinion about how those who have no previous experience with a dVCS should transition to Bazaar. I think it is unnecessarily confusing for them to go straight for the full distributed setup. An intermediate step, where you familiarize yourself with bazaar's interface but use a workflow that is reminiscent of CVS would simplify the transition. My recommendation is: bzr init-repo my-repository cd my-repository bzr checkout URL_TO_UPSTREAM_EMACS_TRUNK emacs Now you have the files ready to work. Why I used `bzr checkout' instead of `bzr branch'? Because the `checkout' creates a "heavyweight checkout", aka "bound branch", which means that your commits go directly to upstream, as CVS does, instead of being stored on the branch waiting for your explicit orders for sending them upstream. Your daily work would consist on: bzr update bzr commit The only additional commands you need to know for now: bzr status # says what you edited, what's in conflict state, etc. bzr resolve [file ...] # For telling bazaar that you solved a conflict. bzr diff [file ...] bzr log [file ...] bzr annotate [file ...] All those commands are accesible through VC/VC-Dired and work off-line, except 'update' and 'commit'. Once you are confident with this and you feel at home with bazaar interface (a few hours is usually enough), you can migrate to a workflow that is fully distributed and that allows you having your own branch in your machine, for committing off-line to that branch and sending the changes upstream in batches when you are connected. The key here is that the basic setup I described can be effortless morphed into whatever workflow you choose to use in the future (converting a bound branch into an unbound branch or vice-versa requires just one command) without having to repeat long and painful operations like re-downloading all the history from upstream, etc. -- Óscar