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: Listing branches with bzr Date: Wed, 02 Dec 2009 12:53:47 +0900 Message-ID: <87ws16uj3o.fsf@uwakimon.sk.tsukuba.ac.jp> References: <83638qms4h.fsf@gnu.org> <877ht6qsf3.fsf@red-bean.com> <87ljhm72vc.fsf@notengoamigos.org> <87r5re5dii.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 1259725747 14165 80.91.229.12 (2 Dec 2009 03:49:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Dec 2009 03:49:07 +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 Wed Dec 02 04:49:00 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 1NFgD5-0006gx-RT for ged-emacs-devel@m.gmane.org; Wed, 02 Dec 2009 04:49:00 +0100 Original-Received: from localhost ([127.0.0.1]:40947 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NFgD5-0004zr-HG for ged-emacs-devel@m.gmane.org; Tue, 01 Dec 2009 22:48:59 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NFgD0-0004ze-3b for emacs-devel@gnu.org; Tue, 01 Dec 2009 22:48:54 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NFgCu-0004yX-Lq for emacs-devel@gnu.org; Tue, 01 Dec 2009 22:48:52 -0500 Original-Received: from [199.232.76.173] (port=43743 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NFgCu-0004yU-F9 for emacs-devel@gnu.org; Tue, 01 Dec 2009 22:48:48 -0500 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:48418) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NFgCt-0002AQ-O1 for emacs-devel@gnu.org; Tue, 01 Dec 2009 22:48:48 -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 6F6658218; Wed, 2 Dec 2009 12:48:43 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 621171A290A; Wed, 2 Dec 2009 12:53:47 +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:118106 Archived-At: Lennart Borgman writes: > Isn't it doing the same work as on the server? Yes. > Is it the network traffic that makes it so incredibly slow? Yes. What you are seeing is bzr using algorithms designed on the assumption that files are local on each individual file via HTTP. > I am thinking about Stephens reply (which I have not had time to > respond to). He mentioned that git uses SHA to identify files why bzr > does not do that? Is that the cause of the time trouble we are seeing? As I wrote before, bzr uses a way to identify files that makes tracking file and directory renames precise and efficient (in git there is some imprecision and much slower). For most other purposes, the bzr file-tracking method and the git content-tracking method lead to equivalent results with varying degrees of efficiency. For a few things git is quite a bit faster, but bzr is not unusable. In any case it is not the cause of this slowdown. The cause here slowdown is that many files are being downloaded by HTTP, and this would be also be true to some extent for git. The big difference is that for some reason Savannah admins think that use of git's smart server is acceptable, security-wise, but they don't like bzr's. Hopefully that can be changed soon, but to get things done in time for the Emacs VCS switch probably only a request from Richard will do. The Savannah admins don't currently consider installation of the smart server a high priority (there's an open SR, and they've explicitly said, "not now, and not soon"). > I would consider that just as serious as a bug. But maybe there is > something I do not understand there. There is. Don't worry about it. This is an administrative problem, not a technical deficiency in bzr.[1] Stefan and Karl are on this, and they're getting help on the technical details that the Savannah hackers need to know from senior bzr developers. And you'll soak up the technical knowledge as you use bzr; it's not something you need to know to get started. Footnotes: [1] Unless you consider having *both* a smart, efficient server and a very easy way for any Joe Hacker with a home page to give others access to his bzr branch a bad thing. :-)