From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thomas Lord Newsgroups: gmane.emacs.devel Subject: Re: MAINTAINERS file Date: Thu, 06 Mar 2008 12:14:40 -0800 Message-ID: <47D050B0.1060608@emf.net> References: <18375.18663.981150.252393@kahikatea.snap.net.nz> <87od9wt19m.fsf@elegiac.orebokech.com> <87tzjnvjhc.fsf@red-bean.com> <87ablffdf7.fsf@catnip.gol.com> <4s4pbm9lrb.fsf@fencepost.gnu.org> <87skz4n6lu.fsf@catnip.gol.com> <87r6enpy30.fsf@catnip.gol.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------050003050305010108070601" X-Trace: ger.gmane.org 1204828665 20867 80.91.229.12 (6 Mar 2008 18:37:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Mar 2008 18:37:45 +0000 (UTC) Cc: Glenn Morris , rms@gnu.org, lekktu@gmail.com, emacs-devel@gnu.org, kfogel@red-bean.com, paul.r.ml@gmail.com, Miles Bader To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 06 19:38:09 2008 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 1JXKyO-0007Yj-Hz for ged-emacs-devel@m.gmane.org; Thu, 06 Mar 2008 19:37:44 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JXKxq-00019X-Sa for ged-emacs-devel@m.gmane.org; Thu, 06 Mar 2008 13:37:10 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JXKxm-00019I-L9 for emacs-devel@gnu.org; Thu, 06 Mar 2008 13:37:06 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JXKxk-00018x-Q8 for emacs-devel@gnu.org; Thu, 06 Mar 2008 13:37:06 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JXKxk-00018u-Ky for emacs-devel@gnu.org; Thu, 06 Mar 2008 13:37:04 -0500 Original-Received: from mail.42inc.com ([205.149.0.25]) by monty-python.gnu.org with esmtps (SSL 3.0:RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1JXKxZ-00042g-P0; Thu, 06 Mar 2008 13:36:54 -0500 X-TFF-CGPSA-Version: 1.5 X-TFF-CGPSA-Filter-42inc: Scanned X-42-Virus-Scanned: by 42 Antivirus -- Found to be clean. Original-Received: from [69.236.65.4] (account lord@emf.net HELO [192.168.1.64]) by mail.42inc.com (CommuniGate Pro SMTP 5.0.13) with ESMTPA id 24709191; Thu, 06 Mar 2008 10:36:38 -0800 User-Agent: Thunderbird 1.5.0.5 (X11/20060808) In-Reply-To: X-detected-kernel: by monty-python.gnu.org: 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:91534 Archived-At: This is a multi-part message in MIME format. --------------050003050305010108070601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Stefan Monnier wrote: >>> As far as I can tell it's fully functional. W.r.t the performance, it >>> seems acceptable and I'd expect it to be comparable to the performance >>> of Arch in similar circumstances. >>> >> Arch is way too slow in general... >> > > Agreed. Hopefully bzr-over-sftp is only as slow as Arch w.r.t the > actual network access, and all the subsequent operations are a good > bit faster. > Disk space is pretty cheap: make sure you have a "revision library set up". If you are importing (or quickly creating) a lot of "history," be sure to create cached revisions on the archive-side to speed-up first-time check-outs. Maybe people already know all that but it was my experience that many times when people complain about arch being slow, they haven't taken those steps. Arch is "heavier" than other systems and, in some ways, is basically "doing more" (than, e.g., git) so, yes, it won't win prizes for commit times any soon. In some ways that's a work-style issue. Arch isn't intended to be used in a mode where, for example, you commit every time you save an editor file. The "zen" of Arch is that each commit should represent a kind of "complete thought" so that the record of changesets is a kind of documentation of the logical steps that were taken in the evolution of a branch. If you find yourself doing commits more than at most a few times per hour, and you're not doing something special like plowing through a bunch of trivial merges, then you might not be using it to its best effect. (Yes, the above is about Arch but I assume it is still applicable to bzr). -t --------------050003050305010108070601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Stefan Monnier wrote: 
As far as I can tell it's fully functional.  W.r.t the performance, it
seems acceptable and I'd expect it to be comparable to the performance
of Arch in similar circumstances.
      
Arch is way too slow in general...
    

Agreed.  Hopefully bzr-over-sftp is only as slow as Arch w.r.t the
actual network access, and all the subsequent operations are a good
bit faster.

Disk space is pretty cheap:  make sure you have a "revision library set
up".   If you are importing (or quickly creating) a lot of "history," be
sure to create cached revisions on the archive-side to speed-up
first-time check-outs.   Maybe people already know all that but it was
my experience that many times when people complain about arch being
slow, they haven't taken those steps.

Arch is "heavier" than other systems and, in some ways, is basically
"doing more" (than, e.g., git) so, yes, it won't win prizes for commit
times any soon.      In some ways that's a work-style issue.   Arch isn't
intended to be used in a mode where, for example, you commit every
time you save an editor file.    The "zen" of Arch is that each commit
should represent a kind of "complete thought" so that the record of
changesets is a kind of documentation of the logical steps that were
taken in the evolution of a branch.   If you find yourself doing commits
more than at most a few times per hour, and you're not doing something
special like plowing through a bunch of trivial merges, then you might
not be using it to its best effect.

(Yes, the above is about Arch but I assume it is still applicable to
bzr).

-t


--------------050003050305010108070601--