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: GNU Emacs is on Bazaar now. Date: Tue, 29 Dec 2009 22:30:08 +0100 Message-ID: <87eimdo4db.fsf@telefonica.net> References: <87d4206n80.fsf@canonical.com> <83tyvaewjg.fsf@gnu.org> <87my11o9fk.fsf@telefonica.net> 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 1262122395 3196 80.91.229.12 (29 Dec 2009 21:33:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Dec 2009 21:33:15 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 29 22:33:08 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 1NPjgM-00051Y-22 for ged-emacs-devel@m.gmane.org; Tue, 29 Dec 2009 22:32:46 +0100 Original-Received: from localhost ([127.0.0.1]:38973 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NPjgL-00038m-0v for ged-emacs-devel@m.gmane.org; Tue, 29 Dec 2009 16:32:45 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NPjgE-00035G-Rq for emacs-devel@gnu.org; Tue, 29 Dec 2009 16:32:38 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NPjg9-00032e-Rl for emacs-devel@gnu.org; Tue, 29 Dec 2009 16:32:37 -0500 Original-Received: from [199.232.76.173] (port=35164 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NPjg9-00032b-LQ for emacs-devel@gnu.org; Tue, 29 Dec 2009 16:32:33 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:55297) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NPjg9-000291-29 for emacs-devel@gnu.org; Tue, 29 Dec 2009 16:32:33 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.50) id 1NPjel-0003qi-Fe for emacs-devel@gnu.org; Tue, 29 Dec 2009 22:31:07 +0100 Original-Received: from 174.red-83-45-255.dynamicip.rima-tde.net ([83.45.255.174]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 29 Dec 2009 22:31:07 +0100 Original-Received: from ofv by 174.red-83-45-255.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 29 Dec 2009 22:31:07 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 62 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 174.red-83-45-255.dynamicip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.90 (gnu/linux) Cancel-Lock: sha1:wzTc4Z9MnhojGvZdyrOOpwL8gfQ= 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:118988 Archived-At: James Cloos writes: [snip] >>> I can imagine that it'll be a significant load on the server, too. > > Óscar> With http/sftp, bazaar transfers a lot of data but as it is CPU-bound > Óscar> too, it does not hit the server too hard. The bzr protocol (or bzr+ssh) > Óscar> causes a noticeable cpu load on the server. > > I was thinking of vm load, but that was dumb, since bzr obviously does > not run on the server in sftp/http mode.... [SIGH] > > Is the VM load an issue in ssh mode, along with the cpu load? The cpu load on the server is only an issue for the bzr[+ssh] protocol. I don't know how much VM load the bzr smart server causes while serving a remote branch operation, but it is worth testing. >>> How painful is it to grab an additional branch from the main repo over >>> sftp, comared to the grab of trunk? > > Óscar> Grabbing and additional branch requires a fraction of the cost of the > Óscar> initial branch. Bzr will transfer only the missing revisions. IIRC it > Óscar> required 22 minutes for the initial branch (trunk) and 4 minutes for > Óscar> multi-tty. > > Good. That is what I hoped for. > > I do see that it transfers much more data than it ends up storing on > disk. A du(1) of .bzr trunk/.bzr is on the order of 200 Megs, but > it (claims to) transfer(s) something like twice that over teh sftp link. > > And my first pull since the initial branch only changed 27 files (25 M, > 1 +N and 1 -D), created a new pack of 1417748 octets, but needed 5 Megs > of xfer to grab those changes. Over the sftp/http protocols, bzr acts very dumb. It needs to read lots of data for knowing which revisions to grab, etc. > I expect that the native protocol is more efficient. The bzr protocol does lots of work that otherwise the client must do if it were using the dumb protocols, so it is significantly more efficient. > Also, given the note about locking, does creating a branch over sftp > create the kind of lock that was described earlier? Or does that only > occur when /pushing/ changes to the sv repo? I used sftp instead of > http even though I am read-only because my last attempt over http > couldn't even max out a DS0 straw, much less a fat pipe. But I'd hate > to block commiters by doing so. IIRC someone here said that bazaar supports concurrent r/w access over http/sftp, which is quite surprising to me as adding info to the history can touch a big area of the metadata, AFAIK. The report about the lock issue seems to confirm that bazaar locks the branch (or repository?) sometimes. I don't know for which operations bazaar locks and if it locks only writes or reads too. -- Óscar