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: Sun, 22 Nov 2009 23:59:29 +0100 Message-ID: <87hbsm414e.fsf@telefonica.net> References: <87zl6vskq0.fsf@red-bean.com> <874op07kb0.fsf@red-bean.com> <87639fr3w7.fsf@red-bean.com> <87vdhfpil2.fsf@red-bean.com> <87einvxy9c.fsf@red-bean.com> <20091118230952.GB908@muc.de> <87my2jw05z.fsf@red-bean.com> <83skc9pbf7.fsf@gnu.org> <87iqd5vw5n.fsf@red-bean.com> <83hbsop394.fsf@gnu.org> 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 1258930929 16397 80.91.229.12 (22 Nov 2009 23:02:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Nov 2009 23:02:09 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 23 00:02:03 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 1NCLRM-0007tF-1r for ged-emacs-devel@m.gmane.org; Mon, 23 Nov 2009 00:01:57 +0100 Original-Received: from localhost ([127.0.0.1]:37737 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCLRL-00028q-OI for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2009 18:01:55 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCLRG-00028c-VD for emacs-devel@gnu.org; Sun, 22 Nov 2009 18:01:51 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCLRC-000271-NN for emacs-devel@gnu.org; Sun, 22 Nov 2009 18:01:50 -0500 Original-Received: from [199.232.76.173] (port=57447 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCLRC-00026y-IP for emacs-devel@gnu.org; Sun, 22 Nov 2009 18:01:46 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:50709) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NCLRB-0005Zr-RK for emacs-devel@gnu.org; Sun, 22 Nov 2009 18:01:46 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.50) id 1NCLRA-0007nl-58 for emacs-devel@gnu.org; Mon, 23 Nov 2009 00:01:44 +0100 Original-Received: from 83.red-83-40-117.dynamicip.rima-tde.net ([83.40.117.83]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Nov 2009 00:01:44 +0100 Original-Received: from ofv by 83.red-83-40-117.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 23 Nov 2009 00:01:44 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 144 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 83.red-83-40-117.dynamicip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) Cancel-Lock: sha1:Xn6bK6XyhMlrhpQOezcm92spFWA= 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:117512 Archived-At: Stefan Monnier writes: >> . The description starts with "bzr init-repo" followed by "bzr >> branch", but in fact all the discussions on the subject I saw till >> now recommend to "scp -r" instead. It is unclear whether any of >> the first commands should be modified, replaced, or removed if the >> "scp -r" method is used. > > Yes, the "scp -r" does the "init-repo" plus fetches the branches. > What it doesn't do is "check out" the branches, i.e. populate the > directories with the files of the branches. So you need something like: > > scp -r bzr.sv.gnu.org:/srv/bzr/emacs . > cd emacs/trunk; bzr checkout > bzr pull sftp://bzr.sv.gnu.org/srv/bzr/emacs/trunk I think you are partially wrong on this. With the scp you are cloning (in the filesystem meaning) the directory where the GNU emacs repository lives. This includes all branches, which means all VC metadata (history, etc). I guess that the administrators used the --no-trees option when they created the repository. So you get all what you need including the files, it is just that they are stored with the metadata and not visible/usable yet. Try this: # Get a copy of the GNU repo: $ scp -r bzr.sv.gnu.org:/srv/bzr/emacs # Create a work branch: $ cd emacs $ bzr branch trunk work The new branch `work' will contain all the files. The `pull' you do at the end is unnecessary because you already have the most recent data from the repository. Your recipe is the right one for testing the CVS->bzr conversion (check that all CVS branches and tags are there, etc). But for hacking, IMO scp is highly discouraged, as there is no guarantee that you obtain the repository on a consitent state and it may completely fail if the administrators fuse the emacs repo into a global bzr repo for all GNU projects. Besides, you usually are interested on one or two branches, not on the whole repository. So for hacking the best thing is to # Initialize a shared repository: $ bzr init-repo emacs-dev $ cd emacs-dev # Get the branch you are interested on: $ bzr branch sftp://bzr.sv.gnu.org/srv/bzr/emacs/trunk # Now you have everything you need on the `trunk' directory, including # files ready to be edited. But you'll better leave it as a mirror of # the branch on GNU and work elsewhere: $ bzr branch trunk work # Use `work` for hacking. Note: the `bzr init-repo' assumes that you are working with the latest stable bzr release (2.0) For previous versions, you maybe need $ bzr init-repo --rich-root or some other variant. Really, now that 2.0 is out for some time, I see no reason for not recommending it and deprecate previous versions. We are having difficulties due to the multitude of supported workflows, and supporting past bzr versions will only create more confussion. > bzr pull sftp://bzr.sv.gnu.org/srv/bzr/emacs/trunk > IIUC scp only works for non-anonymous access, so we'll want to place > a tarball somewhere for download so the scp will be replaced by > "wget+untar". Please note that the tarball method gives you the state of the project at the time it was made, but of course you want to update your files whenever necessary. For that you need read-only access to the repository. If you can give http access to bzr.sv.gnu.org/srv/bzr/emacs, forget about the tarballs and be done with that. >> Also, the above doc.bazaar URL uses the --trees switch to init-repo. >> What is its significance, and do we need to use it? > > IIRC it means that when you do "bzr branch" (aka "bzr clone") you'll get > a branch complete with its files, whereas otherwise you'd only get > a branch without its files (i.e. it would require a separate "bzr > checkout" as I did above in order to get the files). By default, you get a working tree (the files you work on), so "--trees" is redundant. You have --no-tree (branch command) and --no-trees (init-repo command) for explicitly requiring from bzr that it should not create working trees (the actual files you edit on). [snip] > For any kind of development, I strongly discourage lightweight branches, > unless you have very fast and constant access to the base repository > (i.e. most likely not the case if the base repository is the Emacs > repository). Right. [snip] >> . The text says to update the mirror only _after_ pushing the local >> changes from the task branch and deleting that branch. Is it not >> possible or advisable to update the mirror with partially pushed >> changes, while the task branch still exists? (Use-case: while >> working on a new feature, I discover a bug in the existing code, >> and want to fix it without waiting for my final push.) There is no such thing as "partially pushed changes". `push' is an atomic operation that sends a series of commits (by default, those who were not pushed yet) to some other branch. You can push changes whenever you please, and pull changes likewise. The use-case you mention is better solved with a feature branch. For instance: # Suppose you are working on my-feature branch/directory: $ cd .. $ bzr branch trunk bug-fix $ cd bug-fix ...edit... $ bzr commit -m "Fixed blah" $ bzr push sftp://bzr.sv.gnu.org/srv/bzr/emacs/trunk $ cd ../my-feature # Incorporate your bug-fix into your work: $ bzr merge --force ../bug-fix # The --force option is in case you have uncommitted changes on your # branch. It is advisable to not merge upon modified (edited & # ucommitted) files, for not mixed the merged changes with your # modifications. # Commit the merged changes: $ bzr commit file -m "Merged bug-fix" ... keep hacking on your feature ... You could have a branch for that kind of work, instead of creating one each time. [snip] -- Óscar