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: Making the tarball with bzr data Date: Tue, 01 Dec 2009 11:20:29 +0900 Message-ID: <87einfwi36.fsf@uwakimon.sk.tsukuba.ac.jp> References: <4B140ACF.9090808@gmx.de> <874oob955s.fsf@telefonica.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1259633740 7733 80.91.229.12 (1 Dec 2009 02:15:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Dec 2009 02:15:40 +0000 (UTC) Cc: =?iso-8859-1?Q?=D3scar?= Fuentes , emacs-devel@gnu.org To: Lennart Borgman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 01 03:15:32 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 1NFIH6-0000mO-IE for ged-emacs-devel@m.gmane.org; Tue, 01 Dec 2009 03:15:32 +0100 Original-Received: from localhost ([127.0.0.1]:59633 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NFIH6-0000di-2F for ged-emacs-devel@m.gmane.org; Mon, 30 Nov 2009 21:15:32 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NFIH0-0000bz-5g for emacs-devel@gnu.org; Mon, 30 Nov 2009 21:15:26 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NFIGu-0000aG-9l for emacs-devel@gnu.org; Mon, 30 Nov 2009 21:15:24 -0500 Original-Received: from [199.232.76.173] (port=37128 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NFIGu-0000aD-4x for emacs-devel@gnu.org; Mon, 30 Nov 2009 21:15:20 -0500 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:45034) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NFIGt-0005TA-7G for emacs-devel@gnu.org; Mon, 30 Nov 2009 21:15:19 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id 72F988213; Tue, 1 Dec 2009 11:15:17 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id B2D351A290A; Tue, 1 Dec 2009 11:20:29 +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:118014 Archived-At: Lennart Borgman writes: > Why do I have to copy the files? Why can't this setup be done with > the already existing files? Basically, because Bazaar is not git. In git, each object is summarized with an SHA1 hash, and so you can verify that you have a clean tree (with very high probability) without actually comparing the file content. Bazaar uses a different, history-dependent method to track files, assigning a globally unique, *permanent* ID to each file. So in order to verify that you have the right files for the version Bazaar believes to be there, Bazaar must diff every single file. If you think about it, you'll see any other behavior would make Bazaar a very unreliable tool. There no savings in network transport (Bazaar can't send only the content of the version you check out), and no savings in local file IO (in the best case, every file differs in the first byte so you check them all out anyway), by reusing existing files. N.B. Reuse of an existing tree is a theoretical possibility only in git. AFAIK it has not been implemented. In Bazaar, I suspect you can do the following: 1. bzr branch --treeless tmp 2. mv tmp/.bzr But this doesn't save any network transport (you still get all the branch data), and not much time locally since bzr will need to diff all the files to determine which ones to commit (it will believe they have *all* changed based on timestamp). Probably the best procedure is 1. bzr branch bzr-emacs 2. rsync old-emacs bzr-emacs assuming that rsync has appropriate options to ensure that it won't change the stat data (specifically size and timestamp, IIRC) that bzr uses to check if a file has been changed. > I have put my little elisp library nXhtml at Launchpad so you can > download it with bzr. However a lot of people already have nXhtml > installed, but it was not checked out from Launchpad. It came from a > zip file or similar. > > Now I believed that since bzr is a new modern system it would of > course have thought of that kind of situation. No, because Bazaar is a new modern system it assumes you have a new modern network connection with which to download the Bazaar metadata and revision history reasonably quickly. This is a one-time cost per project you work on if you use the workflow recommended in BzrForEmacsDevs. > Maybe my believe is crazy. Maybe this should not be possible for some > reason. But I do not understand why. It is possible -- with git. Emacs isn't using git. And there are things that Bazaar can do (eg, tracking renames efficiently) that git cannot. Unfortunately, tracking renames depends exactly on the feature I described above (tracking files in bzr vs. tracking content in git). (In theory you could do both and get the best of both worlds, but this hasn't been implemented in any VCS AFAIK.)