From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: dhruva Newsgroups: gmane.emacs.devel Subject: Re: Moving to bzr? Date: Mon, 5 Jan 2009 17:09:41 +0530 Message-ID: References: <871vviif6s.fsf@xemacs.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1231155611 17236 80.91.229.12 (5 Jan 2009 11:40:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 5 Jan 2009 11:40:11 +0000 (UTC) Cc: Eli Zaretskii , "Stephen J. Turnbull" , emacs-devel@gnu.org To: "Lennart Borgman" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 05 12:41:20 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 1LJnpa-0002xt-Ej for ged-emacs-devel@m.gmane.org; Mon, 05 Jan 2009 12:41:15 +0100 Original-Received: from localhost ([127.0.0.1]:58278 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LJnoL-0002hE-3u for ged-emacs-devel@m.gmane.org; Mon, 05 Jan 2009 06:39:57 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LJnoG-0002go-9o for emacs-devel@gnu.org; Mon, 05 Jan 2009 06:39:52 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LJnoC-0002fE-SV for emacs-devel@gnu.org; Mon, 05 Jan 2009 06:39:51 -0500 Original-Received: from [199.232.76.173] (port=33738 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LJnoC-0002fA-Pb for emacs-devel@gnu.org; Mon, 05 Jan 2009 06:39:48 -0500 Original-Received: from ti-out-0910.google.com ([209.85.142.185]:5461) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LJno8-0008Ow-H0; Mon, 05 Jan 2009 06:39:45 -0500 Original-Received: by ti-out-0910.google.com with SMTP id u5so5799067tia.10 for ; Mon, 05 Jan 2009 03:39:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Wgv8dO/AxOPQZ6aErhJTSCQvGmTSYQu/MN7AcqbA31E=; b=OAisomOAwSLxxxPYntHsjK6mYLfocnMLbMwsSxMvPaWVoVuPykcnYNQNplo74Lbnxv yhSk7kFuUU1tVDHZDc3ODFM+QrN+vPDs85gRa5Z6uKKQpC/QIt2LZMte0kuGv/mWDWzm MVRyrvbFRKoBeJ4A5dHcHE2y0cYZK+7hKMRH8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=unG8N13WDjWoLCy6nIRMyhPFVh8Wt0bjGI1W9ricG1RdR2feTMrlxjWGPeXTf1QGRZ iVKkDKTPHhbpqYbelFPd+oxmeR8Nk2CiSwSIr4p5OJ3DEA8e4N8yloU1n0pmQ1PdvZ5m /EViiVtW2HmlmfDM1VkghVthdV5/y5Ce3Km5Y= Original-Received: by 10.110.86.3 with SMTP id j3mr4883034tib.59.1231155582062; Mon, 05 Jan 2009 03:39:42 -0800 (PST) Original-Received: by 10.110.8.12 with HTTP; Mon, 5 Jan 2009 03:39:41 -0800 (PST) In-Reply-To: Content-Disposition: inline X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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:107607 Archived-At: Hello, On Mon, Jan 5, 2009 at 3:18 PM, Lennart Borgman wrote: > On Mon, Jan 5, 2009 at 4:50 AM, Stephen J. Turnbull > wrote: >> Eli Zaretskii writes: >> >> > Is "bzr pull" the equivalent of "cvs up -d"? That is, is that the >> > command to resync with the master repository? Because if it is, it is >> > slower than CVS by a large margin (but so is git's 3 min, so I assume >> > "bzr pull" is not the equivalent of "cvs up -d"). >> >> Are you testing on Windows? git has historically had performance >> problems on Windows because its Unix-oriented optimizations are often >> pessimizations on Windows. > > Does this mean bzr is unusable for w32 users (for a large project like Emacs)? I think Stephen was commenting on m$ port of git. I have been using MSYS port of git for doing my official work and pull emacs. I have never had any problems (and hence unsubscribed myself from their mailing list). However, I remember one posting on #git about msys port of git not able to support very large repositories (in gigabytes) and emacs is far from that. The cygwin port does not have any such issues I was told. So, between cygwin and msys port, you are all set to use a working and usable git for serious work. One missing feature in msys git is ability to run the git daemon server, cygwin supports that. I am going to collect the output of 'timeit bzr.bat pull' which is equivalent of 'time bzr pull' and post the results somewhere on the web (need to figure out). Also, I have a pretty high end laptop (IBM Thinkpad T61 with Intel Duo (dual core) and 2GB RAM. It is not loaded as I do all my development using a putty terminal connected to a GNU/Linux box. So, resource is not an issue. The sample output of 'timeit bzr.bat pull' looks like this: Using saved parent location: http://bzr.notengoamigos.org/emacs/trunk/ Now on revision 95263. Version Number: Windows NT 5.1 (Build 2600) Exit Time: 4:53 pm, Monday, January 5 2009 Elapsed Time: 0:04:59.984 Process Time: 0:00:00.046 System Calls: 6639636 Context Switches: 1925320 Page Faults: 299443 Bytes Read: 185970981 Bytes Written: 25746978 Bytes Other: 2649061 From: 95262 lektu 2009-01-05 Fix typos. Current: 95263 gm 2009-01-05 Add 2009 to copyright years. So, it was 1 change set! The memory usage was high too (I have not logged it now). I can get perfmon logs for better analysis if required. Now, git (pulls and updates the local folder too) with all branches: From: commit 7b8942ecec62129282ab75ca8bc009618ec34124 Author: Glenn Morris Date: Thu Dec 18 03:34:16 2008 +0000 Fix reStructuredText funky capitalization. To: commit 5b9823795d0ec55a7a114f9fed93f773a8546908 Author: Martin Rudalics Date: Mon Jan 5 10:29:41 2009 +0000 (x_set_frame_parameters): Make sure height (width) get applied when fullwidth (fullheight) is set. (Bug#1522) Version Number: Windows NT 5.1 (Build 2600) Exit Time: 5:04 pm, Monday, January 5 2009 Elapsed Time: 0:03:11.531 Process Time: 0:00:00.031 System Calls: 4480504 Context Switches: 1324154 Page Faults: 508523 Bytes Read: 565680562 Bytes Written: 102819912 Bytes Other: 1241955 I will start posting the details and hope it helps in deciding using more scientific approach. -dhruva -- Contents reflect my personal views only!